jj has appeared and kicked off a new round of discussion around git ergonomics (and git history was recently added to git), but I don't think enough people know about git absorb which I use daily at work. My current workflow is to set up the rough series of commits that I want in a pull request, and then as I develop I git absorb the fixes into the appropriate commits as I go.
Oh yes, but for more than performance: I'm always compiling by the time I'm fixing up commits. Patching the source code while compiling it is very UB in terms of build system correctness. I don't know how people can work with that.
So the commit that you originally got incorrect, is now correct. If a reviewer comes by and reviews your code afresh commit by commit then they won't have to view something you later changed completely.
This is all dependent on how you structure your unit of change and the commits within that.
This applies to stacked PR/stacked diff workflows followed by many organizations that aren't on GitHub. These workflows focus on atomic, bisectable commits.
another example: write a change, push, get dinged by linter. You wouldn't want that to be a separate commit. You'd want that to have been part of the original change. So you fix it up and git absorb et voilà!
I also use this when running the big CI suite and I find an edge case that broke something I hadn't thought about. Fix the edge case, add a test. git absorb will put the fix into a fixup! commit and I can amend that with the test to pop it all into the original commit.
I use this thing 50-100 times a day when I'm really churning.
absorb is good. I wish it would just rebase for you after creating the fixups but I don't mind the extra step. Have been using this reliably for several years now.
[OP] krig | 11 hours ago
jj has appeared and kicked off a new round of discussion around git ergonomics (and git history was recently added to git), but I don't think enough people know about git absorb which I use daily at work. My current workflow is to set up the rough series of commits that I want in a pull request, and then as I develop I git absorb the fixes into the appropriate commits as I go.
dominicm | 11 hours ago
I'm kinda hoping absorb can leverage history somehow to speed up the pairing performance. It would be a great outcome.
anordal | 6 hours ago
Oh yes, but for more than performance: I'm always compiling by the time I'm fixing up commits. Patching the source code while compiling it is very UB in terms of build system correctness. I don't know how people can work with that.
I use git-revise for the same reason.
accelbread | 4 hours ago
Magit also has integration with it!
git absorbhas been a useful part of my toolbox.zenspider | an hour ago
wait... where?
mdaniel | 5 hours ago
Graphite claims to offer a "stack" aware version https://www.graphite.com/docs/command-reference#gt-absorb
coby | 3 hours ago
Why would you rewrite history just to address review feedback? That seems confusing.
dominicm | 2 hours ago
So the commit that you originally got incorrect, is now correct. If a reviewer comes by and reviews your code afresh commit by commit then they won't have to view something you later changed completely.
This is all dependent on how you structure your unit of change and the commits within that.
sunshowers | an hour ago
This applies to stacked PR/stacked diff workflows followed by many organizations that aren't on GitHub. These workflows focus on atomic, bisectable commits.
zenspider | an hour ago
another example: write a change, push, get dinged by linter. You wouldn't want that to be a separate commit. You'd want that to have been part of the original change. So you fix it up and
git absorbet voilà!I also use this when running the big CI suite and I find an edge case that broke something I hadn't thought about. Fix the edge case, add a test.
git absorbwill put the fix into afixup!commit and I can amend that with the test to pop it all into the original commit.I use this thing 50-100 times a day when I'm really churning.
sluongng | 2 hours ago
absorb is good. I wish it would just rebase for you after creating the fixups but I don't mind the extra step. Have been using this reliably for several years now.
dominicm | 2 hours ago
I believe you're looking for the
-rflag?