6 ms·

A large percentage of git users are unaware of git-absorb (https://github.com/tummychow/git-absorb https://github.com/tummychow/git-absorb). This complements ju

by nicois 11mo ago

A large percentage of git users are unaware of git-absorb (https://github.com/tummychow/git-absorb https://github.com/tummychow/git-absorb). This complements just about any git flow, vastly reducing the pain of realising you want to amend your staged changes into multiple commits. This sits well alongside many TUIs and other tools, most of which do not offer any similar capability.

skydhash 11mo ago
I see the usefulness. But my client is magit, and committing and rebasing are so quick that this will reduce perhaps 30 seconds to one minute to my workflow. And I do not like most rust tools, because they're too dependency heavy.
- kccqzy 11mo ago
  Definitely. The instant fixup feature is just three keystrokes away (s c F). The only thing this helps is when you don't want to spend the extra brain cycles to figure out which commit to fixup on.
- 1718627440 11mo ago
  The task that absorb speeds up is finding the commit where each hunk was last changed. The actual committing and rebaseing is still basically the same.
  - skydhash 11mo ago
    Git blame using `M-x vc-annotate` with Emacs. But If I have a clean PR that usually means one to three commits (If it's not a big refactoring). So the whole point become moot. In magit, if you create a fixup or a squash commit, it will present you with the log to select the target.
    - gpderetta 11mo ago
      Yes, or magit-blame, but if you still have multiple commits in your history that you are working on, and you need to break up the current changes in a bunch of instant fixups, figuring out which one is the right one can be a bit time consuming. I'm not convinced that automatically amending to the last commit that touched that line is safe, but I'm willing to try git-absorb.
      - 1718627440 11mo ago
        > I'm not convinced that automatically amending to the last commit that touched that line is safe, but I'm willing to try git-absorb. It is not, but git absorb only produces fixup commits, you can still change what they change in the autosquash step.
1718627440 11mo ago
It's in the GNU/Debian repo and I guess in a lot of other distros as well.
imiric 11mo ago
I gave it a try a few months ago, and wasn't impressed. About a quarter of the time it got confused about the commit it should squash into, and left the repo in a half-applied state. This inconsistency was enough for me to not trust it when it did work, so I stopped using it. Honestly, it's too much magic for my taste. And, really, it's not much manual work to create fixup commits for the right commit anyway.
Aeglaecia 11mo ago
to me this appears to be trading off a valid change log for neat naming ... i dont see why rewriting history is ever a good idea
- akvadrako 11mo ago
  I find it quite hard to follow PRs when there is a lot of rebasing. I don't really find separate non-time-based commits useful. So I agree but unfortunately it's the norm and policy for some clients. Git-absord by default doesn't squash the fixups though, it creates new ones with special tags for easy rebasing later.

by nicois 11mo ago

skydhash 11mo ago

I see the usefulness. But my client is magit, and committing and rebasing are so quick that this will reduce perhaps 30 seconds to one minute to my workflow. And I do not like most rust tools, because they're too dependency heavy.

kccqzy 11mo ago
Definitely. The instant fixup feature is just three keystrokes away (s c F). The only thing this helps is when you don't want to spend the extra brain cycles to figure out which commit to fixup on.
1718627440 11mo ago
The task that absorb speeds up is finding the commit where each hunk was last changed. The actual committing and rebaseing is still basically the same.
- skydhash 11mo ago
  Git blame using `M-x vc-annotate` with Emacs. But If I have a clean PR that usually means one to three commits (If it's not a big refactoring). So the whole point become moot. In magit, if you create a fixup or a squash commit, it will present you with the log to select the target.
  - gpderetta 11mo ago
    Yes, or magit-blame, but if you still have multiple commits in your history that you are working on, and you need to break up the current changes in a bunch of instant fixups, figuring out which one is the right one can be a bit time consuming. I'm not convinced that automatically amending to the last commit that touched that line is safe, but I'm willing to try git-absorb.
    - 1718627440 11mo ago
      > I'm not convinced that automatically amending to the last commit that touched that line is safe, but I'm willing to try git-absorb. It is not, but git absorb only produces fixup commits, you can still change what they change in the autosquash step.

1718627440 11mo ago

It's in the GNU/Debian repo and I guess in a lot of other distros as well.

imiric 11mo ago

I gave it a try a few months ago, and wasn't impressed. About a quarter of the time it got confused about the commit it should squash into, and left the repo in a half-applied state. This inconsistency was enough for me to not trust it when it did work, so I stopped using it. Honestly, it's too much magic for my taste. And, really, it's not much manual work to create fixup commits for the right commit anyway.

Aeglaecia 11mo ago

to me this appears to be trading off a valid change log for neat naming ... i dont see why rewriting history is ever a good idea

akvadrako 11mo ago
I find it quite hard to follow PRs when there is a lot of rebasing. I don't really find separate non-time-based commits useful. So I agree but unfortunately it's the norm and policy for some clients. Git-absord by default doesn't squash the fixups though, it creates new ones with special tags for easy rebasing later.