4 ms·

Jujutsu has a command which is helpful for this sort of workflow called absorb which pushes all changes from the current commit into the most recent commit whic

Jujutsu has a command which is helpful for this sort of workflow called absorb which pushes all changes from the current commit into the most recent commit which modified that file. (Each file may be merged into a different commit).

metadat 1y ago
Yes, totally useful compared to default git base commands. And also - melding the "changed twice" (or thrice...) mutations into a single commit is a brilliant isolation of a subtle common pattern.
- goku12 1y ago
  git-absorb does exist [1]. It seems to be inspired by a mercurial subcommand of the same name. It's also available in most distro repos. [1] https://github.com/tummychow/git-absorb https://github.com/tummychow/git-absorb
koterpillar 1y ago
git-absorb (https://github.com/tummychow/git-absorb https://github.com/tummychow/git-absorb) does a bit more, figuring out the exact changes that should be fixed up.
- CorrectHorseBat 1y ago
  JJ absorb does the same as far as I understand
- globular-toast 1y ago
  git-autofixup is better and easier to install: https://github.com/torbiak/git-autofixup https://github.com/torbiak/git-autofixup
  - operator-name 1y ago
    Could you elaborate how it is better?
    - globular-toast 1y ago
      They are quite different methods, explained by the respective implementations. IME autofixup finds the relevant commit successfully more often. There's no reason you can't use both, of course. I would always check the results of either before actually doing the rebase.
deleted 1y ago
[deleted]
schrodinger 1y ago
This seems very similar to how I work by default. I sort of think in terms of "keyframes" and "frames", or "commits" and "fixes to commits." Whenever I sit down to code with a purpose, I'll make a branch for that purpose: git checkout -b wip/[desc] When I make changes that I think will be a "keyframe" commit, I use: git add . git commit -m "wip: desc of chunk" (like maybe "wip: readme") if I make refinements, I'll do: git add . git commit --amend and when I make a nee "keyframe commit": git commit -m "wip: [desc 2]" and still amend fixes. Occasionally I'll make a change that I know fixes something earlier (i.e. an earlier "keyframe" commit) but I won't remember it. I'll commit and then do: git add . git commit -m "fixup: wip desc, enough to describe which keyframe commit should be amended" at the end I'll do a git rebase -i main and see something like: 123 wip: add readme (it's already had a number of amends made to it) 456 wip: add Makefile (also has had amendments) 789 wip: add server (ditto) 876 fixup: readme stuff 098 fixup: more readme 543 fixup: makefile and I'll use git rebase -i to change it to reword for the good commits, and put the fixups right under the ones they edit. then i'll have a nice history to fast forward into main.
- ZeroGravitas 1y ago
  I think you might be aware given the specific words you use but for the benefit of others: Git commit --fixup lets you attach new commits to previous hashes you specify and then can automatically (or semi-manually depending on settings) squash them in rebases.
  - pimlottc 1y ago
    You can combine this with the `:/<text>` syntax [0] for matching the most recent commit with a given text in the commit message, e.g. $ commit frobinator/ -m "refactor the frobnicator" [ more work ] $ commit echaton/ -m "immanentize the eschaton" [ oops, missed a typo ] $ commit frobinator/ --fixup :/frobic 0: https://stackoverflow.com/a/52039150 https://stackoverflow.com/a/52039150
  - schrodinger 1y ago
    Thanks, I am —- but I always found it easier to just give the new commit a name I know how to squash rather than type in a SHA. The other post about being able to do it on a substring match sounds way more ergonomic though, I’ll have to try that!

metadat 1y ago

Yes, totally useful compared to default git base commands. And also - melding the "changed twice" (or thrice...) mutations into a single commit is a brilliant isolation of a subtle common pattern.

goku12 1y ago
git-absorb does exist [1]. It seems to be inspired by a mercurial subcommand of the same name. It's also available in most distro repos. [1] https://github.com/tummychow/git-absorb https://github.com/tummychow/git-absorb

koterpillar 1y ago

git-absorb (https://github.com/tummychow/git-absorb https://github.com/tummychow/git-absorb) does a bit more, figuring out the exact changes that should be fixed up.

CorrectHorseBat 1y ago
JJ absorb does the same as far as I understand
globular-toast 1y ago
git-autofixup is better and easier to install: https://github.com/torbiak/git-autofixup https://github.com/torbiak/git-autofixup
- operator-name 1y ago
  Could you elaborate how it is better?
  - globular-toast 1y ago
    They are quite different methods, explained by the respective implementations. IME autofixup finds the relevant commit successfully more often. There's no reason you can't use both, of course. I would always check the results of either before actually doing the rebase.

deleted 1y ago

[deleted]

schrodinger 1y ago

This seems very similar to how I work by default. I sort of think in terms of "keyframes" and "frames", or "commits" and "fixes to commits." Whenever I sit down to code with a purpose, I'll make a branch for that purpose: git checkout -b wip/[desc] When I make changes that I think will be a "keyframe" commit, I use: git add . git commit -m "wip: desc of chunk" (like maybe "wip: readme") if I make refinements, I'll do: git add . git commit --amend and when I make a nee "keyframe commit": git commit -m "wip: [desc 2]" and still amend fixes. Occasionally I'll make a change that I know fixes something earlier (i.e. an earlier "keyframe" commit) but I won't remember it. I'll commit and then do: git add . git commit -m "fixup: wip desc, enough to describe which keyframe commit should be amended" at the end I'll do a git rebase -i main and see something like: 123 wip: add readme (it's already had a number of amends made to it) 456 wip: add Makefile (also has had amendments) 789 wip: add server (ditto) 876 fixup: readme stuff 098 fixup: more readme 543 fixup: makefile and I'll use git rebase -i to change it to reword for the good commits, and put the fixups right under the ones they edit. then i'll have a nice history to fast forward into main.

ZeroGravitas 1y ago
I think you might be aware given the specific words you use but for the benefit of others: Git commit --fixup lets you attach new commits to previous hashes you specify and then can automatically (or semi-manually depending on settings) squash them in rebases.
- pimlottc 1y ago
  You can combine this with the `:/<text>` syntax [0] for matching the most recent commit with a given text in the commit message, e.g. $ commit frobinator/ -m "refactor the frobnicator" [ more work ] $ commit echaton/ -m "immanentize the eschaton" [ oops, missed a typo ] $ commit frobinator/ --fixup :/frobic 0: https://stackoverflow.com/a/52039150 https://stackoverflow.com/a/52039150
- schrodinger 1y ago
  Thanks, I am —- but I always found it easier to just give the new commit a name I know how to squash rather than type in a SHA. The other post about being able to do it on a substring match sounds way more ergonomic though, I’ll have to try that!