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.
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.
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?
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.
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...
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
So `git restore file` should reset the worktree, if you allow an unflagged version of that command.
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.
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.
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.
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.
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.