[_7fvc]

Reading this article, I realize that I'm old now. I still remember wrestling with cvs, svn. Merge, branch were slow and even more challenging. It was much easier to mess up and so difficult to rewind.

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.

[jchw]

I’m torn. Practically Mercurial feels like it should be the winner. The commands are more uniform and predictable.

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.

[andrewla]

> I’m torn. Practically Mercurial feels like it should be the winner. The commands are more uniform and predictable.

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.

[fouronnes3]

Even if you understand the data model perfectly, git still has terrible UX. reset can do 3 different things, a "remote" can mean 3 different things depending on context... I could go on all day. Just the fact that there are parodies of git man pages should drive the point home. (Disclaimer: I love git). Oh and what the hell is 'git rerere' anyway?

[js2]

re)use re)recorded re)solution.

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.

[yepguy]

That sounds a lot like the patch theory stuff from darcs and pijul.

[dllthomas]

You love git because your experience, overall, is far from terrible. It's true that there are a lot of inconsistencies to memorize, and that's a worse UX than the equivalent without those inconsistencies, but that only matters so much. We both speak English - we can cope with inconsistencies in a language.

[jchw]

I don't love Git because it’s got a great UX. I love Git because of what can be done once you get past the awful UX.

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.

[dllthomas]

I guess I'm arguing that UX extends beyond command names and learning curves (while definitely incorporating those things). I'm on-board with the notion that there are aspects of git's UX that are terrible. But as a user, if your experience was awful, you would not love the software.

[jzoch]

I've heard this repeated a lot but honestly find it very untrue. I understand git internals and watched half a dozen talks on hit but still have to Google how to split a commit in two or how to safely rebase vs merge when I'm dealing with too many conflicts in my rebases. How to accept their or my commits during a merge or rebase so I can skip conflict resolution, how to do X or Y. It's just bad UX. It's okay! I don't blame the tool but repeating "it's fine if you understand how it works" doesn't help, it perpetuates the idea that this bad UX is somehow good

[bunderbunder]

> git, ugly as it is, reflects the underlying data model. Once you understand that data model...

This is, like, the very definition of bad/sloppy UX.

[darkpuma]

No, I strongly disagree. Exposing the datamodel can be part of an excellent user experience if your target audience are programmers, as is the case with git. Where git goes wrong is numerous commands that do numerous very different things if given different flags. That has nothing to do with the underlying datamodel being exposed; it's just sloppy planning and design. That part is terrible UX.

[JohnFen]

Perhaps, but speaking personally, that doesn't matter much to me. What matters to me is how much easier a tool makes my job, and of all the version control systems I've used, git is easily the winner.

[bunderbunder]

And I don't want to say that Git isn't an improvement over many other version control systems.

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.

[JohnFen]

Fair enough. I won't say git's UI is intuitive -- it's not. But once I crested the learning curve, I do prefer it over the alternatives I'm familiar with. When I need to do something unusual, I have better luck figuring out how with git than the others.

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.

[lalaithion]

I dunno, I recently switched from ~4 years of using git to mercurial, and I am finding mercurial massively easier to use.

[rjzzleep]

I don't get that argument at all. I came from svn, used cvs and ss and I think I even tried to use Perforce at some point.

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.

[jcranmer]

The man page for git reset states in its first paragraph:

> 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.

[pseudalopex]

Mercurial had "hg record" since 2007[1] and "hg crecord" since 2008[2]. Now you would use "hg commit -i".

[1] https://www.mercurial-scm.org/wiki/RecordExtension?action=in...

[2] https://www.mercurial-scm.org/wiki/CrecordExtension?action=i...

[fanf2]

The Emacs magit status view has an even better version of git add -p: you can hit tab to expand and collapse diffs of files and hunks in the unstaged and staged changes, selectively s (stage) or u (unstage) everything or a file or a hunk. To split a hunk, highlight the relevant part with shift+arrows then hit s or u. It’s brilliant!

[erik_seaberg]

I tried learning hg and arrived at http://stevelosh.com/blog/2009/08/a-guide-to-branching-in-me... which is a crazy complicated answer to what should be the most important question.

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?

[marssaxman]

It doesn't matter if you've learned git's data model or not; its use of terminology is inconsistent and confusing, and its command interface is disorganized and asymmetrical. In that way, I suppose it is very much like a "natural language", and not like the sorts of languages we are more accustomed to using when getting things done. Even if I know exactly what I want to do to the data structure git is managing, that doesn't help me find the commands I need to type to accomplish it. I have been using git for ten years now and I still have to rely on rote memorization of specific recipes in order to get anything done, which sucks because I am terrible at rote memorization.

[darkpuma]

Hg and git have near feature parity, so I don't really lament Hg's loss so much. Sure Hg's CLI is a little bit better, but beyond that it never really offered any really compelling features over git. Mercurial and git is like Honda and Toyota; maybe one is a bit nicer than the other, but they're both offering you more or less the same thing.

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.

[jchw]

Hg actually does go beyond Git in many areas; I did outline a few but my favorites are the improved commit model (stages, natural branching, rewrite tracking,) the commands Git doesn’t have (absorb, evolve,) and the extensibility (see Facebook extensions.)

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.

[darkpuma]

> If Fossil can’t be compared on the same level, maybe that’s a sign it solves fundamentally different problems.

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?

[avar]

If you care about distributed bug tracking you might be interested in, or want to contribute to git-bug: https://github.com/MichaelMure/git-bug

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.

[jchw]

I don’t think people feel locked into proprietary bug tracking, they just choose it out of convenience. You can export data from Github or Gitlab.

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.

[darkpuma]

> "You can export data from Github or Gitlab."

And then do what with it, import it into your own bugzilla instance? Have you ever tried that? It's a nightmare.

[rswail]

From my perspective, your last sentence is the wrong way around. It's not merging the source control into bug tracking, it's merging bug tracking into distributed source control.

[jacobush]

I used Fossil but it became very very slow when the repo size crawled near a gigabyte.

[rswail]

The issue that Fossil addresses from my perspective is the integration of bug/issue tracking and the VCS. The trouble with using Git{hub,lab} or other issue tracking is that the issue control isn't distributed in the same way as the source control is.

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.

[ethbro]

> Mercurial and git is like Honda and Toyota; maybe one is a bit nicer than the other, but they're both offering you more or less the same thing.

As a car guy, Honda makes cars. Toyota makes appliances for people who hate driving.

[recursive]

I hate (or at least am annoyed by) dealing with source control, although I acknowledge the need for it.

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?

[darkpuma]

My personal preference is for Honda as well, but when you sit down in the drivers seat and survey what is in front of you in a Honda or a Toyota, you'll find they have more or less the same things. Perhaps Hondas being set up to be more agreeable to "car guys" is similar to the CLI of Hg not being so obtuse, but both are still nevertheless capable of more or less the same feats. They'll both see you through your commute and either is a bad choice for off-roading.

[Annatar]

As another car guy, I agree. Never quite thought of it that way but it's true.

[dajohnson89]

Driving a Toyota feels like a game/toy. Which puts me on edge, because I feel detached from what the car is actually doing. The handling feels.... too smooth.

[avar]

> Mercurial feels like it should be the winner. The commands are more uniform and predictable.

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

[jrochkind1]

> I.e. yes Git has some UI issues, but those are fixable

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".)

[avar]

There's definitely been a lot of UI fixes in the Git command-line client. I know because I wrote some small number of those patches.

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.

[mannykannot]

Your response to the first point appears to explain why Git largely replaced Subversion, but it is not clear that it applies to Mercurial.

[avar]

I'm not saying it won't, just that transitory UI issues are unlikely to drive a mass exodus from one source control system to another.

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.

1. https://news.ycombinator.com/item?id=19908932

[js2]

I'm an early git contributor and long time user. At the time I picked it up, I was following and using hg as well.

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.

[sc11]

> 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.

There is some work being done on it, including a prototype: https://gitlab.com/gitlab-org/gitlab-ce/issues/31600#note_15...

[phpdave11]

You can use Mercurial with GitHub by using the hg-git plugin, which lets you push to and pull from a Git server repository from Mercurial.

It’s a really nice tool that I’ve been using for several years to push to git repositories.

[MikusR]

When i started using version control for my plain text notes, I initially settled on Mercurial (because of it's supposed better support for Windows), but turns out it doesn't support unicode filenames while git does. So I went with git.

[jhauris]

https://sr.ht supports mercurial now. I haven't used it yet, but it's a nice OSS option.

[zapita]

I used Mercurial exclusively for a long time. I reluctantly switched to Git when it became obvious Github was the place to be if you wanted your open-source project to get any attention.

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.

[emilycook]

> I kind of wish GitLab would implement Mercurial support

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)

[sanderjd]

Yep, mercurial really is better, but it is also noticeably slower. I used git for about a decade, and now use hg at my job. Recently, I used used git again while playing around with something over a weekend. I instantly remembered why I loved it so much. There is really something to be said for commands resolving practically before you have noticed you pressed enter. I wonder if this is inherent or accidental; I don't know the mercurial data model well enough to understand why it would be necessarily laggier.

[alexhutcheson]

Python vs. C makes a big difference.

[paulddraper]

> So why does it never seem to get consideration? I guess it’s because of the insane proliferation of Github and Linux

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.

[otabdeveloper1]

> The commands are more uniform and predictable.

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.)

[teekert]

Git is ugly and daunting when you start with it, but as you get to know it you start to appreciate it's beauty and elegance and it will work for you. Actually I find this with many programming concepts.

[crispyambulance]

Git is neither beautiful nor elegant. It survives because it does the job and a critical mass of people has miraculously brought it to prominence.

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.

[sirsuki]

The reason "the commands are so [messed]-up, inconsistent and counter-intuitive" is most likely that you expect the commands to represent your mental model of the system when in fact they represent the mental model of the system designers.

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.

[rstuart4133]

> when in fact they represent the mental model of the system designers.

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.

[crispyambulance]

That's the best and most plausible explanation I've heard for why the git CLI is the way it is.

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?

[mixmastamyk]

> till I dove in and looked at the underlying data model.

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.

[masklinn]

Meh.

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.

[rusk]

Hence the name I guess ... yeah it's ugly and annoying but you're stuck with it because it's great. Kind of like Linus himself I guess ... I wonder if that's the joke.

[masklinn]

> you're stuck with it because it's great.

We're stuck with it because of network effects. Git is absolutely not great.

[JohnFen]

I think git is great. But that might only be because all the other version control systems I've used are worse...

[gjm11]

> I wonder if that's the joke.

Yup. According to Wikipedia, Linus said: "I'm an egotistical bastard, and I name all my projects after myself. First 'Linux', now 'git'."

[Grangar]

Don't use the UI. Use the CLI. It sucked at first but made my experience tenfold easier down the line.

[masklinn]

> Don't use the UI. Use the CLI.

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.

[rswail]

git aliases make it suck less :D

[noname120]

Even after years of Git usage, `git reset --soft -- file`, `git reset --mixed -- file`, BUT `git checkout file` instead of `git reset --hard -- file` is ugly and symptomatic of Git's lackluster UX.

[bicolao]

This particular pattern should be fixed in a future git (hopefully). There's a new command that supports all these

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...

[fouronnes3]

Two things I don't like in your examples:

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

[bicolao]

Since this is posted on Git mailing list, the reply is here https://public-inbox.org/git/20190515103031.GA29149@ash/

[jnbiche]

imho the natural default for any of these types of commands should be to reset the worktree, never the index. In my experience, people almost always want to review a file before they stage it, even if it's coming from HEAD.

So `git restore file` should reset the worktree, if you allow an unflagged version of that command.

[bicolao]

"git restore file" does reset worktree. Sorry I didn't mention it. If neither --worktree or --staged is present, the default target is the worktree.

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.

[erik_seaberg]

I can't test the index. If the index and workspace are different, the index is wrong. I would like an option to make the index go away (or else become a buildable filesystem dir), and stash whatever I don't want to commit yet.

[bicolao]

> I would like an option to make the index go away

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.

[mleonard]

Hi. Interesting to know thanks!

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

[bicolao]

"git restore --staged" should be the same as "git reset -- file" (--mixed, --soft and --hard cannot be used with individual files).

"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 :)

[mleonard]

Thanks really very helpful!

When you hoping to have git restore in the official git release?

[bloopernova]

Has there been any efforts to add a wrapper around git's commands to make a more friendly command line UI?

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.

[Matumio]

There have been many attempts. I liked easygit a lot (seems to be unmaintained now: https://people.gnome.org/~newren/eg/documentation/). It had really nice docu. It took me a while to memorize all the native git replacements for `eg revert`. Gitless looks like it could fit your needs (https://gitless.com/).

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.

[dotancohen]

> Git is ugly and daunting when you start with it, but as you get to know it you start to appreciate it's beauty and elegance

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.

[JohnFen]

I agree. I still have to use svn in my workplace, but I use git for my own stuff. When things go wrong, I find it easier to fix it with git than svn.

[sAbakumoff]

how about star team? L)