When I first learned git, I thought it's pretty neat. It solves merge, branch, rewind problems. Git is one of the things in life that doesn't work like the way we think. But it turns out to be a better way.
That’s not all it has going for it either. Mercurial has a concept of commit stages to make history rewriting safer. It has a commit model that enables you to work on and manipulate branches of commits seamlessly, without needing named branches. It has not just a tree of commits but also each commit tracks its own history through rewrites. You get cool commands like absorb and evolve. It’s easier to extend than Git.
The only downside to modern Mercurial I can think of is it’s still slower than Git, by at least a bit. But it can scale incredibly far with its extensibility. For example, what Facebook did:
https://code.fb.com/core-data/scaling-mercurial-at-facebook/
So why does it never seem to get consideration? I guess it’s because of the insane proliferation of Github and Linux, which is definitely more a blessing than a curse. But it’s weird. Back in the CVS and SVN days, it didn’t seem like there was ever going to be a ‘network effect’ for source control like there is today.
I kind of wish Gitlab would implement Mercurial support. I bet it would help Mercurial gain more adoption within teams working on closed source projects. I know Bitbucket does, but to be honest that doesn’t really appeal to me much.
Fossil is another matter. Fossil defies pithy car analogies. Integrating the bug tracker into the version control alone is a game changer, and that's not even all that Fossil does.
Sure, the model is similar and Fossil is different. But that is kind of an important note. If Fossil can’t be compared on the same level, maybe that’s a sign it solves fundamentally different problems.
In most setups, the bug tracker and source control are separate, but that doesn’t mean you can’t get bugtracking alongside code either, GitLab provides everything from bugtracking to CI to deploying stuff to Kubernetes.
Not to say Fossil isn’t cool or doesn’t have its place, but if I disagree with the philosophy (and I do, fundamentally,) then I don’t feel like I lose much using alternative software suites.
Or Fossil provides a superset of the others. Like comparing a corkscrew, which only opens bottles of wine, to a swiss army knife that has a corkscrew. They both solve the same problem, but one of them also solves other problems and is generally a more useful tool to keep around in your pocket.
The world didn't lose much with Hg losing to git. But with Fossil losing, we lost a great deal. As a consequence we have a world where people feel locked into the proprietary bug trackers their git host provides. Had Hg prevailed, that situation would be no different. The only way the world would be different if Hg had prevailed would be fewer posts on HN whining about git's interface being obtuse. Not really a substantially different reality, is it?
I mean hell, trac and redmine have been around forever now. Is an open source wiki+bugtracker that revolutionary?
My best guess is that there’s some benefit of merging the source control in, but I’m not sure; it’s not like other environments can’t provide integrated bug tracking.
And then do what with it, import it into your own bugzilla instance? Have you ever tried that? It's a nightmare.
At my previous org I imported our entire Github org into Gitlab EE. Don’t remember much pain, seemed pretty easy to me.
It's aiming to create a fossil-like distributed bugtracker on top of git, with bidirectional importing from e.g. github's and gitlab's APIs.
I want to be able to do a code review, deal with an issue, make changes to source, test etc offline/on a branch and then push all of the changes/impacts (source, issue, comments etc) for distribution to other developers.
As a car guy, Honda makes cars. Toyota makes appliances for people who hate driving.
So does the analogy still fit? And which one is better for people that are merely putting up with the necessity for source control rather than enthusiasts?
Keith Packard's "Repository Formats Matter" post nicely captures how meaningless it is to focus on this sort of thing in the long term: https://keithp.com/blogs/Repository_Formats_Matter/
I.e. yes Git has some UI issues, but those are fixable, whereas e.g. Subversion's UI was way better than Git in the early days, but its repository format limitations inherently weren't fixable.
> Mercurial has a concept of commit stages to make history rewriting safer.
Yeah that's a really neat feature. For what it's worth some people at Google seem to be working on trying to get an equivalent feature into Git.
> For example, what Facebook did[...]
Much of what drove Facebook to Mercurial has since been addressed, e.g. "status" times being slow due to lack of inotify-like integration. That's now a feature of core git. Some of the rest is being worked on and actively upstreamed, e.g. from the GVFS effort: https://vfsforgit.org
To reference a reply of mine to your sibling comment[1], it would have been like going through a lot of trouble to move from Mercurial to Git some years ago just because Mercurial's terminal UI didn't use coloring.
In theory, yes. However, a decade on an I'm not sure any UI issues have been fixed?
It turns out 'legacy' is a hard problem, including just for UI "porcelain". In part because people are used to what there is. (Which is a reason it's hard to get people to switch to something that isn't git either -- enough people have figured out how to do what they need with git as it is, and most people don't like having to learn new tooling).
Everyone agrees that moving from svn to git was a net positive, nobody likes svn better.
Git is pretty good.
But it's UI can be weird. And I am pretty sure if we check back in another 10 years, if people are still using git, it will be with the same basic UI model, little "fixable" will have been fixed.
Doesn't mean it'll be a disaster, we're doing okay with git. But I don't think the "UI issues are fixable" argument carries much weight here.
(Other alternatives may have been better, it can sometimes be a mystery or subject to debate why one product "wins".)
There's also cases where Git's was and still is top-notch, e.g. in the use of terminal colors by default, and opening a pager for you smartly. Both of those were cases where Mercurial trailed behind for a while, although I think now it's caught up in that area.
I concede that Git's command-line UI still sucks in a lot of areas.
What I was pointing out with the "Repository Formats" reference is that one shouldn't conflate deficiencies in the underlying formats with UI deficiencies.
The latter is easy to fix, and the git command-line client doesn't have a monopoly on fixing those things. There's plenty of other top-notch UIs for Git. E.g. Emacs's Magit, and GUI clients like GitKraken, Sublime Merge etc.
Whereas the inverse isn't true. You can't really build a client like Magit on top of CVS.
There is some work being done on it, including a prototype: https://gitlab.com/gitlab-org/gitlab-ce/issues/31600#note_15...
It’s a really nice tool that I’ve been using for several years to push to git repositories.
I think that's true if you're coming from something like Perforce or Subversion and have some notion of what the expectations are around those environments. It's much easier to translate that model into Mercurial commands.
But in the end it's deceptive; git, ugly as it is, reflects the underlying data model. Once you understand that data model, and how the basic commands manipulate that model, then it becomes a very natural language for manipulating the commit chain.
If there's a downside, it's that git doesn't let you get away for too long without learning the data model, while Mercurial lets you live in blessed ignorance until the first time it doesn't work like svn does, and then you're stuck because its data model is not as cleanly exposed, so you need to gently massage it into a good state rather than just surgically moving it to where you want it to be.
The first year or two of Git usage ended in many, many incidents of lost work. That is not good UX for source control, its the most catastrophic UX imaginable for something designed to track source changes...
That’s why the site this post is about exists. If you don’t know about reflog, you are severely disadvantaged... and many of my coworkers at my previous employer certainly did not.
I guess the real point is, just because we, who are experienced with Git, now have a good experience with Git, does that mean Git UX is good? I’d argue no. Bad UX doesn’t usually make software unusable or even unproductive necessarily, in my experience it usually means something more along the lines of, it’s unintuitive and confusing, and takes much more time to learn.
A good example would be something like Blender, especially pre-2.8. Is it bad? No! It’s good software. Is it good from a UX perspective? Well, it has unfamiliar paradigms and it tends to confuse people, so I would say no, and that’s why they’re trying to improve it.
In fairness, Git has done many small things over the years to improve its user experience and to reduce instances of data loss. But Facebook’s chistedit vs rebase -i is a pretty great example of UX differences imo. Git could catch up easily in some of these aspects.
But having said that, I really feel like the experience of expert users also matters and is often overlooked in discussions of UX. And I just don't think people love software when their experience using it is terrible.
It allows git to record and re-use how merge conflicts are resolved. It's an esoteric command that 9/10 users will probably never use. But if part of your day job is, say, merging your startup's[1] local development with that of an upstream project[2], you will come to love this command very very quickly.
1) Rockmelt; 2) Chromium.
I don't see how people consider mercurial "easier", "the winner" or whatever.
I think it's like languages: if you're a french speaker and you translate everything into your native tongue while learning, then of course you won't ever get past roman languages. It's just different.
`git add -p` is my absolute favorite command ever. `tig` is just awesome. The gui clients are so beautiful and take away all the so called uglyness nowadays, though I just can't find myself using anything over git add -p. Nothing in mercurials commandline ever came close to these two. But yeah tig isn't really part of git but at the same time it's been around for so long it might as well be.
> In the first and second form, copy entries from <tree-ish> to the index. In the third form, set the current branch head (HEAD) to <commit>, optionally modifying index and working tree to match.
When your documentation starts by saying (in effect) "this command does several different things", that should be a very strong sign that your command UX has some issues.
[1] https://www.mercurial-scm.org/wiki/RecordExtension?action=in...
[2] https://www.mercurial-scm.org/wiki/CrecordExtension?action=i...
This is, like, the very definition of bad/sloppy UX.
But, IMO, the real sea change there is the shift to a DVCS, and not Git's interface. Within the set of DVCS that I've used, I find Git to be easily the most difficult to understand and work with, and the one where I have to spend the most time reading and grokking abstruse explanations of the tool's implementation details in order to figure out how to deal with some edge case.
I don't think that I'm the only one. My sense is that people whose only DVCS is git are much more likely to love it unconditionally than people who came to git after having first spent significant time on some other DVCS. For my part, as another concrete example, I have to spend a lot more time helping junior devs with source control snafus now that I'm at a Git shop than I did when I was at a Hg shop.
In summary, "Sure it's easy to use, you just have to read this lengthy explanation of its implementation details first," isn't really a compelling argument when you know that there are other competing products that are easy to use even if you didn't spend that much time on RTFM first.
That said, I am not familiar with most of the various version control systems out there, and I could easily be missing something that's genuinely better.
There's just something about git branches and refs that makes sense to me. The CLI commands are a mess, of course—why can "reset" do everything?
Git won because it was a) unopinionated and b) powerful enough to support arbitrary workflows for any enterprise.
For the enterprise, being 'uniform and predictable' is way, way, way down lower on the list of important criteria in version control. (And in fact may even be a negative, due to the weird legacy workflows many enterprises have.)
I found git easier to learn and use. Git has just a few basic concepts underlying how it works. Once I learned blobs, trees, commits, the index, and references (branches, tags, reflog, etc), I understood the model. It wasn't hard to grok a local vs remote repo, how history was a dag, and so forth. From there, I realized all the crazy commands, the baroque UI, these were all just ways of manipulating those objects in various ways. I could always figure out how to make git do what I wanted. It never fought me or tried to tell me I couldn't do something.
hg, by contrast, I felt was always trying to hold my hand. Its model was harder to understand. It required me to adapt to its workflow, instead of allowing me to adapt it to mine. It was generally much less flexible.
I found everything about git more Unix-philosophy like.
I understand completely if you don't want to think about your VCS and just want it to record your changes and otherwise get out of your way, but I wanted a more flexible and powerful tool.
Hi! GitLab employee here. Mercurial support has been a hot-ish topic internally. If you want to weigh in then please comment on this Issue, since Issue interaction plays a big part of how we prioritize https://gitlab.com/gitlab-org/gitlab-ce/issues/31600
(edit: I'm an idiot I should've read the full thread first since someone already linked it. gonna leave it up anyway)
I think the way forward for Mercurial would be to become a Git frontend, or "porcelain" as they call it. That way we would get the best of both worlds: the ubiquitous git format and hosting infrastructure; and the superior UI and workflow of Mercurial. I'm sure it would be a difficult undertaking, and might require difficult trade offs between compatibility, performance and usability. But I think it would be worth it. For one, Mercurial would become relevant again, and probably get a lot of new users. A lot of users would probably come back. And Git users would also benefit from the renewed competition between competing frontends.
Part of it is not wanted to learn multiple VCS's. Part of it is Github. Part of it is performance.
I honestly believe that if Github supported Mercurial, or if Bitbucket had "won" over Github, then Git:Mercurial would be something like 4:1.
Git has a shitty UI when you start with, and it still has a shitty UI years down the line.
The underlying model is neat and interesting, but that you have to know it to find any usability or elegance is an indictment.
We're stuck with it because of network effects. Git is absolutely not great.
Yup. According to Wikipedia, Linus said: "I'm an egotistical bastard, and I name all my projects after myself. First 'Linux', now 'git'."
I'm specifically talking about the CLI.
> It sucked at first
It still sucks. It'll always suck. The project is unlikely to fix any of the suck.
git restore --staged file # reset the index from HEAD
git restore --worktree file # reset the worktree from the index
git restore --source=HEAD --staged --worktree file # reset both the index and worktree from HEAD
Still in development [1] so if you think something can be improved, I'd love to hear it.
[1] https://github.com/git/git/blob/pu/Documentation/git-restore...
Would you mind giving the current commands to achieve the three things you just listed?
That way I learn the future restore command along with the current approach and you description. T
"git restore --worktree" is the same as "git checkout -- file".
"git restore --source..." should be the same as "git reset --hard -- file" if --hard was made to work with individual files.
Though "git restore" should make it clear (or clearer) to the user what they want to restore without resorting to more mysterious options like --hard/--soft. So if that's not obvious from my examples, I think I've failed :)
When you hoping to have git restore in the official git release?
If things go well, maybe v2.23.0, unless we find serious UX flaws and scrape the whole thing.
So `git restore file` should reset the worktree, if you allow an unflagged version of that command.
By Git design, you will have to face the index when you have merge conflicts. I don't know how to avoid that (and now is not the time for fundamentally change how conflict resolution is done).
But yeah, the other times, I think you can just live just fine without knowing or touching the index.
> I can't test the index.
I'm not trying to convince you to use the index. But to me, the way I test the index is commit it. Then I could use "rebase -i" to revisit the old commits (i.e. the index content) and test or make more fixes if needed.
It still restores worktree from the index though. But if your workflow ignores the index, then index should be the same as HEAD. "restoring from index" and "restoring from HEAD" will mean the same thing.
First, the default source changes depending on the target. In my opinion it would be more intuitive and simple if the default source is always HEAD. The documentation for --source in your link probably makes sense for a git developer, but not at all for a user. (Especially the part about its default value if absent).
Second, rename "--staged" to "--index".
So in summary, to update your examples, how about:
git restore --index file # reset the index from HEAD
git restore --worktree file # reset the worktree from HEAD
git restore --worktree --source=index file # reset the worktree from the index
git restore --index --worktree file # reset both the index and worktree from HEAD
git restore file # reset the worktree from HEAD
I've tried maybe 3 different GUIs for git and none of them really seemed to help that much. However my usage of git is pretty basic, with branches and tags being about as complex as I get.
The problem is, in the end, you'll still need to know the original git commands with all their quirks in addition to the easier commands, because that's what you'll find on stackoverflow or when asking colleagues or inside of error messages. And those command names will either clash with the names used in plain git or are different partially-overlapping concepts (`git reset` is the worst offender here). So eventually you'll need to memorize twice as many things.
What I will NEVER be able to understand is WHY the commands are so fucked-up, inconsistent and counter-intuitive. It doesn't have to be that way.
If git feels comfortable, it's only because you've crashed and burned it so many times or suffered though countless google searches to eventually remember the commands that are appropriate for your workflow.
I once felt it was weird till I dove in and looked at the underlying data model. Then It struck me and all the awkwardness evaporated and the commands actually make sense to me now.
Everyone says that and I've done the same. Quickly forgotten and left with the same inscrutable commands and looking up explanations on stack overflow.
It sure doesn't feel like that.
Instead it feels rather like a lump of code I'm dealing with now. The needed to add feature X, so they did a brief look for the easiest place to bolt it on. In the code I'm dealing with now that meant y2k stuff was placed in with the tracing code, I presume because the trace headers were used everywhere y2k was needed so they didn't have to add new modules.
In Git case "git reset" has so many features only tangentially related it looks to me the person adding the feature must have followed the same "I need X, I don't want to add or even think about how the CLI is structured so I'll just sneak it in with CLI command Z which looks vaguely similar". And thus we end up with the a similar mess to the code I'm dealing with.
In Hg's case someone evidently put a lot of thought into the overall mental model the CLI would create, and came up with something rather neat. Sadly it doesn't always reflect how it operates underneath, so it can confuse people when things go wrong. When the abstraction created by the CLI breaks, you end up having to do what all people do abstractions leak and learn two things: both the abstraction and how it really works underneath. But Hg's CLI is so well designed casual users will never have to deal with it.
In git's case the CLI bears little relationship to anything. Because nothing is where you expect nor does quite what you think it should things go wrong really quickly. That forces users to learn and think in terms of the underlying data structure which creates a lot of pain up front, but in the end you are always better off understanding things in terms of how they work underneath.
The interesting thing is git is _so_ bad the official git doco has a really good section devoted to describing what is happening underneath, which makes learning it fairly straight forward. Hg doco doesn't do that. While there are some descriptions of how it works underneath it's interwoven in with the description of the CLI, so you can't just read one smallish section and get the big picture. Worse, you can never be sure whether they are describing the model presented by CLI, or what actually happens to be bits and bytes. This makes the jump to real understanding how Hg works harder than git. It's weird how things turn out. I guess which is better depends on the situation.
In any case, please don't dignify git's CLI by claiming it conforms to someone's mental model. To paraphrase Linus, if it does, that someone must have been a demented ferret.
IDE's do try to smooth the edges of working with git, but it's never optimal, I know because I do occasionally have to drop into the git commandline with visual studio. I think IDE integrations just plaster over the mess and cut-off access to stuff you actually need to use from time to time. In other words, I don't think it's feasible, for instance, to only use git through the visual studio IDE.
Every once in a while people will talk about "porcelain" in the git commandline-- it's the notion of creating "ergonomic" command line semantics that behind the scenes are just compositions of the traditional shitty git commands. While I appreciate the pun, it still seems like it is avoiding the root problem.
Ultimately, I just can't understand: why isn't it possible to "clean up" the git CLI so that it's coherent and semantically compatible with how people use the thing? A million or so people use this tool for countless numbers of projects. How much time and effort could be saved by making it so that people can just remember commands, use them effectively, and stop having to throw away work again and again by blowing away folders and starting over with a "fresh" clone... simply because it's easier to start-over than to figure out the correct incantations when you're under time pressure?
This, exactly. Git was written by Linus Torvalds. You could literally replace the word "Git" in that sentence with any other software written by Linus Torvalds and it would remain just as valid. The guy writes software that has a learning curve, but does does its job elegantly. He's not writing software for the social-media-no-attention-span crowd.