Comment by l0b0 | Hacker News Reader

Comment by l0b0 | Hacker News Reader

Parent Full thread

It is necessary but not sufficient for any new contender to do at least the following to have any chance of taking over:

- Interoperate with the major player(s), currently Git and in many places unfortunately still Subversion. svn2git probably did more for Git adoption than any other feature or tool, because it allowed a fairly painless transition without losing information.

- Solve at least one big problem with the current contenders. Git made it possible to run VCS without a separate server program and sped up VCS operations massively. Both of those were huge. Looking at the Fossil home page[1] it does have some features I personally have wanted in VCSes, such as integrated "bug tracking, wiki, forum, and technotes," but the devil is very much in the details of how that actually works (How easy is it to write your own custom frontend or add business-critical bug tracking fields, for example?), and it's not like we don't already have good bug trackers, wikis etc.

Just as a tangent, some issues (but not necessarily major or fundamental, depending on who you ask) with Git as it works right now:

- Does not use cryptographically secure hashes, and has no clear migration path to a different hashing mechanism.

- Git Annex is not yet built in.

- The command line is complex, including many niche subcommands and tons of rarely used options.

- The command line is inconsistent, such as `git rm` vs `git branch --delete` vs `git remote remove`.

- It is based on a less than ideal theoretical model of patches[2]. IMO this is the most exciting development in VCSes since Git.

[1] https://fossil-scm.org/

[2] https://pijul.org/model/

I've seen nobody complain about the commit messages.

Commit messages are not versioned.

I can't go back and change the commit message to fix a typo or add something that was missed without changing the history.

This always bothered me somewhat but now that I have non native and native people on the team that can't spell, I feel the pain everyday.

But you can go back and change a commit message with ammend? Or are you wanting to change other people's?

https://www.atlassian.com/git/tutorials/rewriting-history#gi...

Look at the URL: "rewriting-history"

Ammending changes the hash of the commit. That doesn't matter if you haven't pushed it yet but if you have, you can't push the change upstream without force-pushing.

And if I want to change a commit message further back in history (regardless of my own or of somebody else), it would branch off at that point from the upstream git history.

What I want is that you could put multiple comments onto the same commit with different timestamps. Like git versions files, it should also allow to version commit messages.

> Ammending changes the hash of the commit

Not necessarily. Fossil's `amend` command works by adding additional information to the repo that the web UI and commands like `fossil info` look at when building up information intended for direct consumption by the user.

In this way, you can edit commit messages, rename branches/tags, add/remove tags, etc. to historical check-ins without breaking the blockchain / Merkle tree of commits.

This allows Fossil to keep all of the historical information about what happened to a given file, commit, ticket, etc. while still allowing a coherent presentation of the current state of affairs to the user.

You can accomplish something like this by using git-notes (https://git-scm.com/docs/git-notes). You'd have to have your own tooling to read/write these in a convenient way of course.

Yes but they are just a patch over the missing functionality.

The key point is "your own tooling". Git has a great tool universe but unfortunately you immediately lose many tools if you go beyond what the core offers.

> unfortunately still Subversion

Which is a better choice than Git for most projects, to be honest.

Everyone's has their own tastes and preferences, of course, and I respect that yours is different than mine. That said, I used and loved CVS and then SVN for years and didn't get why all the kids were fussing around with this new Git thing. I finally made myself try it for about a week. At the end of that experiment, I ported all my repos from SVN to Git and quickly set to purging all Subversion-related knowledge from my brain. There's literally nothing about SVN that I prefer to Git, other than its UI was a little more pleasant.

I actually LIKED having a central repository, which many of us still seem to prefer (i.e. GitHub, GitLab, Bitbucket). I switched to git mainly because my colleagues were all using it. I found it difficult to use, at first, because of my expectation of a central repo. Many years in, however, I see extreme value in having all your history locally. Specifically, never having to worry about a server crashing or your "host" going out of business.

Same. I didn't get what was better about a distributed system for small projects, until it fully clicked with me that my copy was just as "official" as any other sitting around, and that any "server" was a copy that we collectively decided was going to be the one of record. I can't imagine any plausible scenario in which I'd go back to having a central SVN-style server.

Having an official central server is precisely what you want in most development environments. Being able to go back to any prior version of the code is tremendously useful and something git can't do.

For most of us, even with DVCS there is one copy of the repos that is more important than all the rest - the one attached to the CI or deployment tools. It’s only decentralized as long as this copy has only short periods of unavailability. Hours are bad, days are much worse.

Linus seems to have a very different development model than almost all of the rest of us. And if Linus is asynchronous, then so is the codebase he maintains.

If you or I have eight different PRs going it’s because we have eight different promises being made to customers. Rejecting them has real consequences that we feel. For Linux many of those are externalities.

> I actually LIKED having a central repository, which many of us still seem to prefer (i.e. GitHub, GitLab, Bitbucket).

You're confusing a hosting service with being forced to use a centralized repository.

Take GitHub, for example. If git was centralized them you would not have forks, multiple remotes or multihosting, or could even work independently of the remote server.

With Git, you can even set up a repo in a network file system somewhere, or even a USB thumbrive.

Git makes it easier to do a fork but you could certainly fork a subversion repo. I’m fairly certain you could sort of a merge process across multiple upstreams.

Git does far more than making it easy to fork: it makes it trivial and inexpensive.

Meanwhile SVN supports forking in the sense that it supports copying directories.

The "fork" concept is not native to neither Subversion nor git.

You are probably thinking of branches and tags, and those are used similarly in both systems. They are a bit more convenient in git since they are created in constant as opposed to linear time.

Copies in Subversion are only metadata. Since partial clones are native to the system, it is simple to present both branches and tags as file paths. It was likely considered an easy user interface. Everything is a file and all that. In comparison, git users must learn the git object naming scheme, otherwise things can end up very confusing should you have a directory and a branch with the same name.

> You are probably thinking of branches and tags,

No, I was referring to forking projects, in the sense that Git allows for creating brand new and independent repositories that clone the version history up to a point in time and enable to add the origin Git repository as a remote repository.

SVN also does not support branching or tagging, as it actually supports only copying directories around a file system.

> They are a bit more convenient in git since they are created in constant as opposed to linear time.

I would argue that branches are nicer in git because it makes merging so much easier.

Having history available locally also means you can perform interesting operations on history -- like "git blame" -- without making the server do all the heavy lifting.

Yeah, other than locking I would argue that a DVCS is better at even the things a non-distributed VCS is good at.

The problem is, is that git will happily destroy history. git blame is not useful because it doesn't tell you who authored the line of code.

Right, especially after a "squash", which seems to be the standard way to merge branches in the companies I've been working with recently. (Which is, ironically, also the way Subversion merges branches. With the exception that "svn blame -g" will go into the commits which were squashed if you want. An option which doesn't exist after a "squash" on Git.)

> The problem is, is that git will happily destroy history.

No, people will happily destroy history. Git is just a tool.

Fossil's opinion on this is that history is an immutable record of project history. It may be messy and unfortunate at times, but it is what happened, and it shouldn't be altered in place any more than you'd do that with an accounts ledger.

In extremis, Fossil offers the "shun" command to remove improperly-committed artifacts, but even then it's subject to a lot of restrictions. (https://fossil-scm.org/fossil/doc/trunk/www/shunning.wiki)

> Fossil's opinion

Tools don't have opinions, people do. Fossil is just inflexible.

You don't want to alter history? Don't do it then. Git supports not altering history just fine.

I can't control what other users of the repo are doing, so it's not that simple.

If you are their superior, other users disregarding your orders is s social problem, not a technical one. If you aren't, it's a good thing they are able not to do what you want.

Tools being more flexible is strictly a good thing. If they are misused, the person that misused them is responsible. It is that simple.

> Which is a better choice than Git for most projects, to be honest.

That's pretty subjective. Most engineers I interact with personally know how to use Git but not SVN. I'd argue the opposite is true base on my subjective experience.

Really depends on where/how you're using versioning, team familiarity, etc.

It took me maybe eight months before I was willing to perform open heart surgery on a subversion repo. Two years to dare to try the same thing with git, and I was much more anxious about the whole thing. At the three year mark I have the same ambivalence about things working out that I did in less than a quarter of the time with the previous system.

That’s a little too much to explain away with variability.

Disagree. SVN was always a pain. Committing is really slow and merging is bad (particularly for things like directory renames).

If all you had before was CVS then SVN wasn't a pain.

Atomic commits and file renames.

SVN had improvements over CVS, but it still had obvious pain points. So there was still an obvious opportunity for a better VCS to come along.

Sure but you could say the same about Git.

With time, the standard requirements rise and we get more demanding.

How about a VCS that not only diffs line by line but saves the diffs as editing delta?

Or that understands the syntax of the code and can differentiate a variable renaming from an actual code change?

Or connecting different repositories is hardly solved with Git. Submodules suck, grafting even more so. Or you can't make one repository out of two and keep their Git history intact.

How so?

Less overhead, a better UI.

Better support for large and binary artifacts

horrendously slow `svn log`, locking files, bad branching… I only used it when I was a student but I don't miss svn at all.

I’ve been wondering if we need a slightly more general tool for tracking changes, that happens to have a VCS commandline as a first class client of that system. The problem is how to do bindings in many languages, or share one binding with some sort of IPC/RPC protocol.

I have some collaboration tools I’d like to write but creating my own edit histories and conflict resolution is daunting.

- Does not use cryptographically secure hashes, and has no clear migration path to a different hashing mechanism.

https://github.com/git/git/blob/master/Documentation/technic...

Thanks; admittedly the last time I looked into this was a few years ago. Glad to see it gaining traction!

Reply on news.ycombinator.com