Pretty clever impl of a tool. I'll be using it, thanks.
Git-absorb: Git commit –fixup, but automatic
11–20 of 278 posts
Re: Git-absorb: Git commit –fixup, but automatic
#12Uhm, I do a lot of git rebase -i HEAD~2 where I just squash the commit on the latest or sometimes I need to reorder and move the fix commits in specific commits in Pars that multiple commits, which I then need to push force. Is this for a similar use-case? I am not familiar with fixup or how it works.
You can also just press `c`, then `F`, in magit.
Re: Git-absorb: Git commit –fixup, but automatic
#13you 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 a problem neither I nor anyone in my last 10 years of working with code has.
Re: Git-absorb: Git commit –fixup, but automatic
#14I 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 that mistakes are rare, but I'm not sure I would trust it enough to not have to review its work anyway.
Re: Git-absorb: Git commit –fixup, but automatic
#15This sounds very useful, I frequently reset soft and recommit in batches of related changes before PR and this sounds like it streamlines integrating updates quite nicely
Re: Git-absorb: Git commit –fixup, but automatic
#16FWIW, 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.
[dead]
Re: Git-absorb: Git commit –fixup, but automatic
#17I 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.
Re: Git-absorb: Git commit –fixup, but automatic
#18As 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 like a problem worth solving properly rather than going around.
To sum up, I'm not convinced by the elevator pitch. However, I am keenly aware that the workflows of developers differ vastly across industry, company size, technology etc. I'd be interested to understand what problems this or similar tools solve?
Re: Git-absorb: Git commit –fixup, but automatic
#19you 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. This is not an ok practice, it's only acceptable because too many people don't have a habit of making their own bed and much bigger kinds of technical debt get ignored because in the end it's about shipping stuff, so you just sigh and say "oh, whatever".
Re: Git-absorb: Git commit –fixup, but automatic
#20you 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 preference for always squashing PRs comes from a place of either not understanding atomic commits, not caring about the benefits of them, or just choosing to be lazy. In any case, the loss of history inevitably comes at a cost of making reverting and cherry-picking changes more difficult later, making `git bisect` pretty much worthless, and losing the context of why a change was made.