Git fixup is magic (and Magit is too)
34 points by facundoolano
34 points by facundoolano
I use git-revise, which is more efficient since it doesn't realize the intermediate trees on disk.
I feel like learning to use git rebase -i solves all sorts of awkward questions around "how do I fixup", "how do I squash", "how do I reorder".
Looks scary.
jj squash accepts target revision as an argument. Or you can just switch to the revision using jj edit and change it directly
the Magit tip at the end doesn't look scary though! Magit makes a lot of opaque git a lot less scary, and frankly I wish a Magit inspired TUI was shipped with git for everyone who doesn't use Emacs.
But then of course, a lot of Magit's power (but not the use in this case!) is tied directly to its deep integration with the editor. If only every editor could have a porcelain as good as Magit..
the Magit tip at the end doesn't look scary though
Yeah this is one of the things I do more or less every day, and it's even more ergonomic than in the video. c F <pick commit> C-c C-c and it's done.
there's this https://terminaltrove.com/gitu/ https://github.com/altsem/gitu but it's still early days for it i think
but i wish it had a better hunk staging ux. visual line selection like in vim mode is the best way to do small linewise staging imo.
install doom emacs and you have a working magit ootb. I don't use emacs as an editor... just for magit and mostly defaults.
a lot of Magit's power (but not the use in this case!) is tied directly to its deep integration with the editor
I don't know about that. I remember I routinely used a dual setup where I had a normal (non-emacs) editor and a second window just for magit (emacs). No deep knowledge of emacs was required, I think I knew maybe 3-4 key combos altogether.
Related: git-absorb
Basically git-fixup, but it automatically determines the target commit.
I tried using this for some time but I always had to double check the patches before squashing them. It does get them wrong sometimes, and if you autosquash then you have to reset the commits. I can’t recommend this.
The author doesn't say anything about the possibility of merge conflicts when reordering commits, nor how one might handle them.
I suspect that merge conflicts are the primary source of the fear around rebasing mentioned in the article.
Git fixup is indeed a great tool; I use it basically daily. But I think the article should also mention that there can be conflicts during the rebase, and that's where the difficulties start.
So my suggestion is: try out the workflow from the article, but also experiment with a fixup commit that conflicts with another commit.
My approach is usually: commit the normal changes and the fixup commits in an ever-increasing list of commits; and then do a "fixup session" where I try to do multiple interactive rebases to move each fixup commit to its correct place, starting from the oldest fixup. At that stage I try to estimate for each fixup how likely the chance for conflicts is. The "easy" fixups I reorder in one or two rebase commands; for the conflicting ones I do a separate rebase command for each commit, painstakingly solving the conflicts for each one (using git-gui and Meld).
Come to think of it, it would be nice if Git would give me a hint which of the fixup commits are going to cause conflicts during rebase. OTOH, before I start to write new tools, maybe I'd better try out stuff like JJ first.
I like having a clean and linear commit history so I did it manually a lot. I tried jj and GitButler more recently and both are excellent tools that make it much easier and less scary.