I actually think the cmdline is easier for that case.
I liberally use .gitconfig shortcuts (in fact I have shortcut to edit .gitconfig itself!), and use g camdne for that one. It would be g cane but a is taken up by the more common add.
magit has a great interface for this: you can stage the changes to the commit you want to fix, the press c F and select a commit from your recent history that the staged changes fix, and it will create the fixup commit, stash other changes if needed, rebase the fixups into the original commit, and pop any stashes that it created.
Dangit, I need to change the message on my last commit!
git commit --amend
…but staging your next commit loads the footgun. If you try then try to amend the last message, the footgun goes off and blenders what you wanted to be a new commit into the last commit.
Anyway, leaving aside Git’s Mutually-Supporting Network of Fortified Footgun Emplacements (which the site author clearly resents no less than I do): Oh Shit, Git!?! / Dangit, Git!?! is just really nice to have at your shoulder when things inevitably fall apart. Big help when learning a system: knowing that screwing up can be undone, and that YOU can undo it. Which is what Oh Shit, Git!?! gives you.
Git documentation has this chicken and egg problem where you can’t search for how to get yourself out of a mess, unless you already know the name of the thing you need to know about in order to fix your problem.
Well, unlike a GUI app, you’re supposed to learn how a CLI tool works before you use it.
I think some programmers miss how CLI and GUI software are different and how each are meant to be learned. GUI software shows you your options and lets your learn as you go with progressive disclosure, but limits what you can do to certain intended functionality. On the command line, you’re not guided, so you learn things bottom up by proactive study. The point of that is that you can combine tools creatively in unintended ways. If you run –help or read man pages only when you get stuck, you don’t learn the wealth of capabilities available to you. You get the worst of both worlds.
If Git is the main thing you use the shell for, as it is for many, you might learn only a few commands and never really understand what’s available to you. But Git is a tool that remains uncommonly useful year after year. All study you devote to it will pay off, so why not dig in?
As much as I love Git and consider myself a hard-core user who can recover anything from reflog etc, I still mess up cherry-picking merge commits from time to time and hate how hard it is to pick the same commit twice to separate its contents into two commits in rebase.
I had the fortune of getting on board fairly early, having people around me draw me pictures of commit trees when I had questions, and I went on to reading release notes etc for new features. But for proper study, something like the manpages aren’t too great.
A great many online guides either remain on a high level or don’t make the low-level stuff approachable.
Less technical people have a GUI you’ve never seen, and you have to show things the user has no understanding of, and can’t get easily, or can’t be arsed because Git is imposed instead of chosen, and doesn’t want to know about or understand “graphs and shit”. On the level of “pull, stage, commit, push” all else is irrelevant and fortunately that’s the most of it for these guys.
I hope the official tutorials are the best nowadays, because studying Git can be as cumbersome as Git itself.
Having said all that, I do agree the payoff his huge.
I didn’t know there was a toned down version. I like the sound of “Oh shit, git?!” a little better, though.
(Though I now see the banner announcing the milder version.)
We should probably make a version that blames the user, not git’s complexity while we’re at it. It’s only fair. “Oppsie, I didn’t git it right.”
Easier way to amend a commit:
git-gui(comes with git!)I actually think the cmdline is easier for that case.
I liberally use
.gitconfigshortcuts (in fact I have shortcut to edit .gitconfig itself!), and useg camdnefor that one. It would beg canebutais taken up by the more commonadd.magithas a great interface for this: you can stage the changes to the commit you want to fix, the pressc Fand select a commit from your recent history that the staged changes fix, and it will create the fixup commit, stash other changes if needed, rebase the fixups into the original commit, and pop any stashes that it created.I reach for
lazygitas a TUI fairly often to do related tasksSee also “Flight rules for Git”: https://github.com/k88hudson/git-flight-rules
…but staging your next commit loads the footgun. If you try then try to amend the last message, the footgun goes off and blenders what you wanted to be a new commit into the last commit.
Anyway, leaving aside Git’s Mutually-Supporting Network of Fortified Footgun Emplacements (which the site author clearly resents no less than I do): Oh Shit, Git!?! / Dangit, Git!?! is just really nice to have at your shoulder when things inevitably fall apart. Big help when learning a system: knowing that screwing up can be undone, and that YOU can undo it. Which is what Oh Shit, Git!?! gives you.
Well, unlike a GUI app, you’re supposed to learn how a CLI tool works before you use it.
I think some programmers miss how CLI and GUI software are different and how each are meant to be learned. GUI software shows you your options and lets your learn as you go with progressive disclosure, but limits what you can do to certain intended functionality. On the command line, you’re not guided, so you learn things bottom up by proactive study. The point of that is that you can combine tools creatively in unintended ways. If you run –help or read man pages only when you get stuck, you don’t learn the wealth of capabilities available to you. You get the worst of both worlds.
If Git is the main thing you use the shell for, as it is for many, you might learn only a few commands and never really understand what’s available to you. But Git is a tool that remains uncommonly useful year after year. All study you devote to it will pay off, so why not dig in?
As much as I love Git and consider myself a hard-core user who can recover anything from reflog etc, I still mess up cherry-picking merge commits from time to time and hate how hard it is to pick the same commit twice to separate its contents into two commits in rebase.
I had the fortune of getting on board fairly early, having people around me draw me pictures of commit trees when I had questions, and I went on to reading release notes etc for new features. But for proper study, something like the manpages aren’t too great.
A great many online guides either remain on a high level or don’t make the low-level stuff approachable.
Less technical people have a GUI you’ve never seen, and you have to show things the user has no understanding of, and can’t get easily, or can’t be arsed because Git is imposed instead of chosen, and doesn’t want to know about or understand “graphs and shit”. On the level of “pull, stage, commit, push” all else is irrelevant and fortunately that’s the most of it for these guys.
I hope the official tutorials are the best nowadays, because studying Git can be as cumbersome as Git itself.
Having said all that, I do agree the payoff his huge.