> stash some of my changes, switch branch, cherry pick a commit, switch branch, do an interactive rebase reordering commits and dropping one, pop one of my stashes
> working with code becomes a fluent experience, rather than fighting with your tools
I also do this regularly, but on my terminal. I don't feel like I'm fighting the git tools. Is this a common experience?
I enjoy using git GUIs as well, especially for visualizing branches, commits and diffs. I just don't understand why the git commands seem to cause so much trouble.
What I dislike with git terminal UI is that commands reflect the innards of git, not what the user wants to do. It also forces a deeper understanding of the innards for basic commands than ought to be necessary.
Examples where undoing an operation looks totally different to doing it:
- To stage a change you `add` it, to unstage you `reset HEAD`
- To commit you `commit`, to undo a commit you `reset --hard HEAD^`
The last example is also where you get pointed to an unsafe command for a fairly benign operation. Uncommitting is not particularly dangerous, but anything with `--hard` ought to give people a pause for thought. If you mistype it and nuke more than the last commit, that's also a bit bad - and fairly easily done.
Some other examples include shenanigans around pushing and pulling remote branches. After 10 years of using git, I still need to google it each time.
I think these commands are an accurate and reasonable representation of its inner state, but IMHO users should at least have the option of being somewhat isolated from it. Git is not a tool for algebraic manipulations on directed graphs, it is a version control software.
It has to be said, to git's credit, that although the commands are confusing to some (myself included), the tool works very well. I wanted to like mercurial more, but ended up going back to git, as much as I dislike the UI.
Yes, except... again, this is fighting fire with fire.
If you don’t know git internals, mistype a non-obvious command and lose a bunch of commits, then “look in the reflog” advice is frankly adding insult to injury.
The reflog is awesome! It keeps pointers to commits that have been dropped, rewritten by rebases, stuff like that.
Git is garbage collected, even if a commit is dropped from a branch it won't simply disappear immediately afterwards. The object is still in the git repository and it can still be reached, most easily through the reflog. Only when garbage collection is performed will any unreachable commits be deleted.
> It's really hard to lose changes once they've been committed.
I've still managed to do it (or maybe I used git rm to delete some files that weren't committed?) so let me give one more shout out to 'git fsck' which saved me here.
Yeah, git is certainly a low level tool. That's actually what I like most about it. There's a few fundamental concepts I get to manipulate directly with git commands. I like dealing with innards like this because I can form a mental model of the tool. High level tools are a lot harder to understand.
I think the problem with add, commit and reset is they aren't low level enough. The reset command in particular is juggling several concepts at once: HEAD, the index and the working tree. The add and commit commands work with fewer concepts: working tree to index and index to commit, respectively.
I too google the commands I don't use often. There's no shame in that.
I probably pushed and pulled O(100) remote branches over the past decade (jeepers I'm getting old), so roughly once a month. It's not that rare, yet I still haven't memorised them, because I find them so unintuitive.
Once a month is close to my usage and it's often enough to remember things in principle but not often enough to remember the d#$%#$%^#$n syntax with all its obscure details.
Depends on the result. I do interactive rebases extremely often, I don't have to look up how it works.
Sometimes I have to use some command I'm not familiar with. Sometimes familiar commands gain new options. It's perfectly okay to use some reference for that. Also, "more time" is like 1 minute.
But this in fact reinforces my overall point. I don't want to be messing with `reset`, hard or soft. What is `reset`? [I now know because I had to learn, but I'd really rather not].
What I want is `uncommit`, or something like that.
That’s a valid point. I think there’s a near consensus, even among people who admire Git and use it constantly (like me, although I’m no expert), that the porcelain commands are confusing in some respects.
On the plus side, Git’s man pages are (sometimes) useful and pretty complete. In this case, if you type `man git-commit` you’ll get a thorough rundown of all the options and it will be clear which one you should use to get what you want.
EDIT: Also, since there are three arenas to keep track of, the file tree, the index, and the commit history, even if there were an `uncommit` command it would need all the flags that `reset` accepts. So it would just be `reset` renamed, which you can do yourself. But maybe some of the `reset` options should be broken out into separate commands.
- git revert {rev} to nuke changes and go back to how the world was
- git uncommit to return to the state literally before git commit
- git unstage to unstage a file
The latter arguably should go with git stage but it’s a bit late for that. NB git add and git rm are totally not inverse operations...
So then I can uncommit, and unstage if need be. Reverting is for discarding changes, and should come with an interactive confirmation prompt and other safety and hygiene messages.
> git uncommit to return to the state literally before git commit
This is ambiguous because there are many such states.
1. Clean working tree, before you began hacking on the code.
2. Modified working tree.
3.1. Modified working tree with staged changes.
3.2. Clean working tree with staged changes.
It's impossible to know which state you want to go back to without telling git. That's what hard, mixed and soft resets do: they bring you back to states 1, 2 and 3.2, respectively.
The default is a mixed reset. I suppose state 2 is what most people want when they try to undo a git commit. So it already does the right thing by default, no?
The only remaining problem is the git reset argument. An undo command will always reset to the previous commit, there should be no need for arguments. Stuff like HEAD^ or HEAD~1 is quite obscure to the uninitiated. We could certainly have a git undo command that runs git reset HEAD^ and allows hard and soft resets. Not sure why it doesn't already exist. Has anyone ever attempted to get that merged into mainline git?
This creates a new commit that reverses the changes of a past commit. That’s different from undoing your last commit, as in, you made a commit but then changed your mind, and want, say to make some more changes before you commit. (Explained in man git-revert.)
If git at least had good man pages. The man-page's description is "Given one or more existing commits, revert the changes that the related patches introduce, and record some new commits that record them." [1] I have a hard time parsing that to mean what it's supposed to mean.
It contains a note that's much better at explaining what git revert does, then goes on to explain alternatives for other things you might want to do, but doesn't mention how to undo a commit without creating a reverting commit.
“ I have a hard time parsing that to mean what it's supposed to mean.”
Can’t disagree. That part could certainly be written better. I’m not saying I would want to learn Git from the man pages, but they’re pretty good in general after learning it elsewhere.
They are decent for reference, and some are genuinely great (like git-everyday [1] or git rebase [2]). But just as often as they are helpful they just leave me scratching my head, either because they are too deep in git-lingo or because they forget to clarify some crucial details
> Git history is intended to be immutable when working with others.
That's another pet peeve (though maybe less git's fault): immutable, yes, but then rebase is pushed quite liberally. Arguably not by git itself, but by many online learning resources.
It's convenient, and mostly works, but then occasionally really stings you.
...yet undoing the last commit, arguably the least aggressive of history-rewriting commands, remains awkward.
It's also very wise to make sure you disallow force pushing to master/main/production. If you force push to a topic branch, it's usually ok. If you accidentally overwrite someone's changes, it's because you are working together and you can communicate that you messed up and for them to `pull --rebase` or however you want to resolve it. Usually that is. There's always room for disaster :)
> Usually that is. There's always room for disaster :)
For me, this is where the problem with got lies. I use so many of it's commands infrequently enough that I don't know where the weird disastrous edge cases are, where I should use.
I think git would greatly benefit from a topical man page; a list of common and uncommon situations that shows the recommended commands for solving them, and explains what those commands do. I know that hundreds of random "guides" exist, but are they outdated, are they cannon, do they have bugs? When your UI is esoteric, situational documentation is really important.
Ya, the git UI is not great. It has improved a ton over the years but still not great. Have you ever seen Git Koans? It's good for a laugh. https://stevelosh.com/blog/2013/04/git-koans/
Oh right. I always neglect to do that mostly out of laziness of typing it out on the command line. It's funny, though, I maintain a branch plugin for vim (it's a fugitive extension) and I recently accepted a PR to switch `--force` to `--force-with-lease` yet I still don't do it. I need to start doing it!
How is "git reset HEAD~" "awkward"? It's not obviously named, but as was noted above, if there was git-uncommit, it would need every option that git-reset has, and so it would just be an alias, without the final argument.
"History is immutable" is generally accepted as describing the contents of commits, not their id's or relative ordering.
The default for `git reset`, which is `--mixed`, may do what you want. The difference between `--mixed` and `--soft` is that the former resets the index as well as moving the HEAD pointer; the latter only moves the HEAD, so if you’ve `git add`ed any changes, they will remain staged.
Yeah, keeping track of Git’s three areas (files, staged changes, repository) can get confusing. After some thought I think my advice to you to use `git reset --soft` would be better as just `git reset`, because that’s a neater “starting over”: it’s more of an “undo” of the last commit action, I guess. I often find myself reaching for `git reset --hard` after screwing up and not feeling like tracking down how I broke things.
"- To commit you `commit`, to undo a commit you `reset --hard HEAD^`"
You're not meant to delete commits like that. Git encourages you to stop "lying about the past", and you will run into a fair amount of trouble if you try to do so with shared history. You don't remove a commit "backwards" and change history; you add a new commit that undoes the previous one (git revert)
Couldn't disagree more. To me, one of the massive advantages of Git over other VCS tools is the support and completeness of its ability to edit time. You are the editor not just of the content under control, but over its branched evolution. Accepting this and working with time gets you to a next level of control.
The first step in this process is really internalizing the tree of commits, and seeing branches not as lines of development as much as simple pointers on that tree. In many VCS systems, branching is a big deal. In Git, a branch is just a smart tag that is automatically updated by HEAD. Users new to Git need to get comfortable creating branches at a whim as the tree grows.
The next step is getting comfortable with editing the tree itself. Primarily, I recommend using interactive rebasing liberally. This has multiple positive side effects:
1. It causes the author to think at a higher-level of the primary artifact they're constructing — the tree of incremental changes.
2. Authors begin to think about the repository as more than a dumb file backup system, but instead as a history with true utility, and so begin to construct "stories" in that evolution that are instructive and useful to future readers of that history.
3. It takes the author out of the flow of time, and encourages them to think about ways to change the past (within limits, of course) so that the constructed history is improved.
All of this, of course, with the caveat that shared history changes must be coordinated (and frequently avoided). You can get very far thinking this way just about your un-pushed topic branch.
There's a very real philosophical difference between those who see VCS as a secure audit trail (where changing history is "lying about the past"), and those who see a repository as a whole constructed artifact of intrinsic value, wholly editable as its contents. In this latter view, editing a line of source isn't "lying" about that line's contents, and neither is editing time.
Interactively rebasing your local changes instead of sharing a hodgepodge of brain vomit is great, but don't go around rebasing history that's already out there between a team of developers unless you have a really, really good reason to.
I did specify that rewriting shared history is going to cause you trouble (unless you really know your way around things), but apparently it wasn't clear enough
Reset is a powerful command that happens to work for the “uncommit” use case. I use reset for a completely different use case: my CI system watches a specific branch for changes and when they occur builds it with a specific configuration. If I reset-push a branch, I get a build of that branch with that configuration.
After the pandemic started and I had to witness over screen share how colleagues "use" (fight) git with all sorts of GUI tools, I had to realize that no GUI can be good enough while one doesn't understand git, or, even worse, it can be contraproductive, because people using these GUIs _think_ they understand, but they don't.
I even ended up creating a (tailored)
2x90min git course...
All that said, I heard magit praised so many times, I still have some hope that it's really as good as its reputation.
(Tried fugitive, which is the vim-world's answer to magit, even learned it properly but realized I always juzt <C-z> to the terminal and do stuff with the cli)
1. Discoverability. It'll display the contextually relevant options and commands at most points. By using magit, you're learning the git CLI commands at the same time, including commands that you'd normally never come across without a comprehensive read of the manual or release notes.
2. Fewer keypresses. Also, extra shortcuts for some common operations.
3. The bits that CLIs aren't very good for: staging and unstaging pieces of files, viewing conflicts.
(I do still use the Git CLI a lot of the time too.)
I think (2) is why I use it, it's just much faster. It doesn't let you skip over understanding Git, it just makes you work faster.
I also think that the experiences of:
* looking into a stash and applying only selected changes from it,
* browsing all your changes and staging only some of them,
* quickly killing changes that you simply want to drop, e.g. not commit and remove from your edits
I tend to avoid using stash in that fine grained way because branches are cheap in git, and you get a rich set of operations using a local branch to stack up unorganized code changes. Rely on stash on only very quick setting aside of work then returning to it. If I stash and find it needs to live longer than that - I’ll stuff it into a named branch.
Re: 3 ... I find that the CLI ("git add -p") works here when the scale of the changes I've already carried out is fairly small and there are not too many orthogonal changes in the file tree that I want/need to commit separately. If that happens, it's off to magit I go.
I'm usually a pro-GUI person but I've always found git GUIs to be confusing/trying to paper over the model in a way that made me not like them. Though I don't mind what IntelliJ has. Maybe I need to give this magit tool a try as well.
Magit is absolutely fantastic and it reduces friction, discoverability and joy. rebasing is easy. commiting is easy. staging is easy. discovering is easy. everything is easy. it's incredibly powerful and also incredibly easy to use. it's simply the best software i've seen written in a long time.
sounds like hyperbole but it's not.
edit: magit is like if you spent months crafting a bunch of aliases for the command line and then made a nice little menu of all of them and committed that to memory but also has it as a popup. and even then magit is an order of magnitude better... handily so.
The underlying model of git is not too hard to understand, and is actually pretty elegant. There are a number of good explanations online, including the one you linked.
The git tool itself, though, often operates at a much higher level of abstraction. I think that's more where the reputation of being hard to learn comes from. For instance, you'd probably need to write a paragraph or two to explain what "git checkout <branch>" does in terms of the actual object store. Add to that that the CLI is poorly designed - many commands have misleading names, a given command will do completely different things depending on the flags, there's a lot of implicit / counterintuitive behavior, and so on. See https://stevelosh.com/blog/2013/04/git-koans/ for some funny examples.
That's a really cool article. The wording could be a lot simpler but the important part is that it does not abstract the concepts. They don't need to be abstracted because they are really simple.
Situations can become very complex, especially when someone does not know what they are doing. Developers need to learn the priciples without lies and overzealous simplifications. If you know what's going on it's a lot more doable to not end up in a super complex situation, but not a lot of people have a really good explanation of git even if they understand it very well themselves.
After trying a couple of times, I haven't been able to get used to magit, and I gave up. I'm very used to the git command line interface, and magit is just too different from that. For instance, it seems to assume I want to operate only on a file, whereas most of the time I want to operate on the whole repository. I have no idea why someone would want to work like that.
I found it was taking a lot of extra research to get it to do what I wanted, and I was completely confused by its choice of default behaviours, so I gave up trying. I would welcome an interactive tool that is more oriented around the way the command line tooling works, but magit does not seem to be it.
I do have magit installed however, because I really like how it controls emacs buffers while using interactive rebase. But I never use the rest of it. I have no interest in trying to memorize which hotkey does what, and how to bend yet a new interface to my will (that apparently disagrees with my preferred default behaviour), when I already know the git command line.
If you start from the magit status buffer, most things operate on the repo, except file-specific commands like staging, unstaging, etc. For those, if you run the command with your cursor on the heading, rather than with it on a file (e.g. on the “unstaged files” heading rather than on a particular file), it will ask for confirmation and apply the operation to all of the files.
More generally, magit applies operations on whatever the cursor is on, when it makes sense to do so. This is very convenient e.g. for staging parts of a change at different granularities: I can stage everything, then unstage a file, then stage a hunk within that file. It only takes a few keypresses, compared to a long set of commands followed by dredging through add -pi.
There is nothing wrong with using git commands in the terminal.
There is also nothing wrong with copying your entire tree to a different directory, diffing, applying patches by hand, and keeping track of what goes where.
Those are different levels of automation for the same fundamental task, but they are all legitimate solutions to the same problem, although you might end up spending more or less time to perform the same fundamental task, depending on the level of automation.
> There is also nothing wrong with copying your entire tree to a different directory, diffing, applying patches by hand, and keeping track of what goes where.
What? There is plenty wrong with that. I've worked with people who did that. There are lots of problems with this approach. It's extremely hard to work with and it only gets harder the more people are involved. At least in git the commits have unique identifiers, everything is hashed and checksummed automatically, branches are properly tracked, etc.
I've even worked with non-programmers whose version control was emailing each other files named like:
Presentation final final REALLY FINAL (2) (3).ppt
It was a hell unlike anything else I had ever experienced before.
> I don't feel like I'm fighting the git tools. Is this a common experience?
Yes. Today I spent way too much time explaining to a coworker that what he was complaining “should be easy to do but seems impossible” was actually quite simple, only to spend ages explaining how git works, why he wasn’t understanding the paradigm. And after all that help what he needed to do was simply to “git checkout feature-A && git merge master” we didn’t even touch on rebasing, and it’s not like he hasn’t used git before, he had at least half a decades worth of experience working with codebases managed in git.
And this is far from the first time that I’ve had to help out people with something that seems extremely straight forward to me and others who have git under our skin, but is overly complex and difficult to people who might not be experts but have worked with git for several years in a state of “minimal viable knowledge”.
Git has the same problem as it’s creator, it is arrogant, and has for way to long tried to explain the fact that new users find it difficult with “well they are just dumb” instead of accepting that it needs to make its user experience and interface more intuitive. Some of these changes are finally happening now, so I no longer have to explain why “git checkout” is used for seven completely unrelated things, but there are still tons of cases where the “straight forward way” to do something is only accessible to people who have spend way too much time doing deep dives with git and fully explored all the edge cases just for the fun of it.
It doesn’t help at all that googling issues is swamped with advice of “just force it” or “delete the repo and clone it again” which can cause permanent damage to the codebase, for a tool that is at its center suppose to avoid permanent damage to your codebase. No matter how stuck up some blinded advocates of the “git is and has always been perfect”-camp you are, everyone should understand that needing to give advice like “and if you have an issue don’t Google it, go see me or another git expert first to avoid loosing code history” is at its core spotlighting fundamental issues in the tool interface.
“minimal viable knowledge" describes my git knowledge. I simple don't have time to become a git expert. After all git is only a source control tool, there are way more important things to deal with that impact our customers.
> I just don’t think there is much value in learning more. It’s just a version control system.
I think it's not a matter of "just" a version control system; it's vital enough to (most of) our jobs that being more than just "minimally viable" good at it is an integral part of being reasonably competent.
But who am I to talk; at work, I almost exclusively use Informatica's built-in "version control system", which IMO... isn't much of one; actually, hardly is one in the first place. Getting to use git (or similar) again is what Idream of. Then again, maybe that just means I'm only "minimally viable" with Informatica's system. :-)
(All out of Spätzle, have to wait for next "Alpenfest" week at Lidl. :-( )
I like having both. I use fugitive in vim which is great for partial staging, blaming, and committing (and status). Almost everything else I do on the command line. I will also commit from the command if I already happen to be there. The one thing fugitive is indispensable for is looking at a file on a different branch right in the editor.
> I also do this regularly, but on my terminal. I don't feel like I'm fighting the git tools. Is this a common experience?
My big hang-up with interactive rebases is that I do them just infrequently enough that what exactly a set of choices will yield—what's going in the commit message, et c.—is something I have to sit there and reason about for a really long (by the standards of something that really is not that complicated an operation) time. I can also never keep it straight when editing messages in-line will have an effect, and when it'll be ignored (in some commands it is, IIRC, in others not? I can never remember, but either way, why the hell let me edit it if it won't do anything?)
What I could really use is a live preview of what the effects of my current choices will be.
I prefer to do my interactive rebases in steps, instead of all at once.
If I want to rebase changes onto a different commit, re-order them and squash some of it, I'll rebase as-is first, then do another rebase and reorder everything so that squashes are next to each other (and yes, sometimes this means unnecessary conflict resolutions), then a final rebase to squash. I'll edit messages last.
Interactive rebases are my favorite git feature. I get to pick, drop, reorder, reword, fixup, squash, split and of course rebase commits. Pretty much everything I need to create a nice history before pushing.
I don't feel like I am either - I think some people are not fans of CLI. Full disclosure: I also don't "get it" when people say they can't use tar without looking up the help/man pages.
I get by with less than 10 git commands - in rough order of decreasing frequency: pull, commit, add/rm, push, stash, checkout, merge, and more rarely bisect, revert and reset.
"I just don't understand why the git commands seem to cause so much trouble."
To me the git command line is one of the tools that are great if you use them often. But if you use it less often it's really hard to remember the correct syntax especially since it's really easy to mess things up. (If know WPF, the binding syntax is in the same category. Really powerful but if you take two months break you struggle with the syntax). It really bugs me in git when normal things need 3 or more parameters and if you forget one of them you mess things up.
Years ago I worked with mercurial for a while and I thought the commands were much cleaner and easier to remember.
You probably don’t feel like you’re fighting your front door when you walk out of your house or apartment also right?
All that means is that git tools, and your front door, work well once you have mastered them. The ease of use and discoverability of tools over the life of their learning curve is what determines if they are a Norman door.
For lots of people, using a Unix command line or Git for the first time feels like a Norman door. This is why other interfaces exist (like guis) for the same tools.
I was like you for a really long time. Then, I watched someone do stuff in Magit that took longer or I struggled with to get perfect in the terminal. Took a few weeks to get comfortable, but once I did, it was really nice.
If you know git cli very well, most of the stuff are straight forward. Most people struggle with git if they have not spent the time to understand how it works.
But there is one thing I believe is still not-very-smooth in the git cli: splitting hunks.
if I do interactive add in git, and I get small hunk that adds a line, deletes a line, adds another line, and deletes a line, then if I want to include only the addition of the second line, it is pretty annoying in git cli. In magit, it is basically selecting the line and pressing "s".
> I also do this regularly, but on my terminal. I don't feel like I'm fighting the git tools. Is this a common experience?
Trying to stash some of the changes is pretty annoying, yes. New files don't want to cooperate with stashing, and there's no way to stash just staged things like making a commit; you have to use -p.
> working with code becomes a fluent experience, rather than fighting with your tools
I also do this regularly, but on my terminal. I don't feel like I'm fighting the git tools. Is this a common experience?
I enjoy using git GUIs as well, especially for visualizing branches, commits and diffs. I just don't understand why the git commands seem to cause so much trouble.