[deleted]
Git-absorb: Git commit –fixup, but automatic
21–30 of 278 posts
Re: Git-absorb: Git commit –fixup, but automatic
#22The thing that I never knew I needed, but I predict within a few days I won’t be able to live without. Thank you!
Re: Git-absorb: Git commit –fixup, but automatic
#23As a frequent user of fixups, this feels like a solution for already broken workflows. > Instead of manually finding commit SHAs for git commit --fixup Assuming you are using fixups, is this actually a problem? I could see this being a possibility if you are: A. not practicing atomic commits or B. have so many commits in your branch that this is a chore. A. seems unlikely if you are already using fixups and B. seems…
How would you manage long-lived branches that are periodically rebased against the master branch (when there is a release, for example)?
Re: Git-absorb: Git commit –fixup, but automatic
#24I tried using this tool after seeing recommendations for it, but IME it got the parent commit wrong enough times that the work to undo the damage was more than if I had looked up the commit myself and used `--fixup` instead. So I moved back to this manual workflow pretty quickly. I prefer having full control over my commit history, and this tool is too much magic for my taste. I'm sure that it could be improved so th…
If it just automatically created the fix up commit and moved it to the proper place in the commit tree, I’d be happy with that. You can then run a one-liner to merge the fix up commits after reviewing.
Re: Git-absorb: Git commit –fixup, but automatic
#25I tried using this tool after seeing recommendations for it, but IME it got the parent commit wrong enough times that the work to undo the damage was more than if I had looked up the commit myself and used `--fixup` instead. So I moved back to this manual workflow pretty quickly. I prefer having full control over my commit history, and this tool is too much magic for my taste. I'm sure that it could be improved so th…
I use lazygit for this. Keyboard driven TUI which lets you easily re-order/squash commits with minimum fuss. Being able to see them all laid out means no futzing with identifying the right ids.
I rarely refer to commits by their IDs in these cases, though. More often than not I use the relative `HEAD~n`, when it's easy to determine `n` visually. With a few aliases, the manual fixup workflow really doesn't take much effort.
Re: Git-absorb: Git commit –fixup, but automatic
#26FWIW, I've been using this alias for the past couple years for fixup commits, and I've been happy with it: > gfx='git commit --fixup $(git log $(git merge-base main HEAD)..HEAD --oneline| fzf| cut -d" " -f1)' It shows you the commits on the current branch and lets you select one via fzf. It then creates the fixup commit based on the commit you selected.
If it only lets you select one, that's strictly less powerful. What if I want some parts of it into one commit and another parts into another? The `hg absorb` works for this case.
That sounds like what `git add -p` is for, stage part of the current changes.
Re: Git-absorb: Git commit –fixup, but automatic
#27I tried using this tool after seeing recommendations for it, but IME it got the parent commit wrong enough times that the work to undo the damage was more than if I had looked up the commit myself and used `--fixup` instead. So I moved back to this manual workflow pretty quickly. I prefer having full control over my commit history, and this tool is too much magic for my taste. I'm sure that it could be improved so th…
If it just automatically created the fix up commit and moved it to the proper place in the commit tree, I’d be happy with that. You can then run a one-liner to merge the fix up commits after reviewing.
That's exactly what it does by default.
Only if you pass --and-rebase does it actually do the autosquash rebase for you.
Re: Git-absorb: Git commit –fixup, but automatic
#28FWIW, I've been using this alias for the past couple years for fixup commits, and I've been happy with it: > gfx='git commit --fixup $(git log $(git merge-base main HEAD)..HEAD --oneline| fzf| cut -d" " -f1)' It shows you the commits on the current branch and lets you select one via fzf. It then creates the fixup commit based on the commit you selected.
If it only lets you select one, that's strictly less powerful. What if I want some parts of it into one commit and another parts into another? The `hg absorb` works for this case.
Might be able to use the multimode flag in the fzf command above and it should let you select more than one using Tab and Shift+Tab.
Re: Git-absorb: Git commit –fixup, but automatic
#29you don't want to shove them all into an opaque commit that says fixes, because you believe in atomic commits. Sure I do. The whole branch will be squashed anyway before it's merged in, and a single "fixes" commit while still on its own branch will be easier to track in a PR for addressing everything pointed out earlier. I mean, don't let me stop anyone from using this or --fixup if this is your flow, but this solves…
Good for you, but you (and, apparently, everyone in your last 10 years of working with) would have a problem if I was the one reviewing your commits. I mean, to be fair, I often did let it slide (for political/social/practical reasons) and use autosquash, but I always actively discouraged it, so if you are a junior or a new hire with uncertain usefulness status, I'd at least talk to you about that and ask you to fix…
It has always been enough for me to trace a change back to its original pull request. Extra granularity might be nice sometimes but never essential. And I do a fair bit of digging through git history. Not sure what makes it "not an ok practice". Squashing works fine and lets the 80% of people who don't care spend their efforts thinking about something other than a perfect git history.
Re: Git-absorb: Git commit –fixup, but automatic
#30you don't want to shove them all into an opaque commit that says fixes, because you believe in atomic commits. Sure I do. The whole branch will be squashed anyway before it's merged in, and a single "fixes" commit while still on its own branch will be easier to track in a PR for addressing everything pointed out earlier. I mean, don't let me stop anyone from using this or --fixup if this is your flow, but this solves…
Every team is free to choose what works best for them, but IMO always squashing PRs is not a good strategy. Sometimes you do want to preserve the change history, particularly if the PR does more than a single atomic change, which in practice is very common. There shouldn't be a static merge type preference at all, and this should be chosen on a case-by-case basis. At the risk of sounding judgemental, I think this pre…
git bisect is still perfectly useful. It will locate the squashed commit/pr which is more than enough for me to zero in on whatever the bug is.