Hacker News Reader

Comment by shaftway | Hacker News Reader

> > You just switch to that commit, fix the typo, and switch back to where you were. Or fix the typo where you were and squash the fix, and only the fix, into the commit that introduced it.

> That sounds the same in Git?

I've always struggled with this myself, and would like to update my git knowledge. Can you walk me through the commands to do this? Let's say the commit id is `abcd1234` and it's 5 commits ago.

In JJ I'd do this:

    vim file/with/typo.txt
    jj squash -into abcd1234 file/with/typo.txt

Or if I was feeling more pedantic I'd do:

    jj edit abcd1234
    vim file/with/typo.txt
    jj edit <<my latest commit ID>>

View on HN

You have the same two options in Git:

    vim file/with/typo.txt
    git add file/with/typo.txt
    git commit --fixup=abcd1234
    git rebase --autosquash -i

For some reason I need to pass --interactive/-i, even if I don't actually want it to be interactive. I am not sure if this is just a bug in my Git version or if this is intended.

The git commit step can also be replaced with git-absorb, if you have this installed and abcd1234 was the last time you modified these lines.

The second approach is this:

    git rebase -i abcd1234~
    # do 's/pick abcd1234/edit abcd1234/' in your editor
    vim file/with/typo.txt
    git rebase --continue

I believe this only works when there are no other uncommitted changes.

So you would need to stash after the fixup commit and pop the stash after rebase. Or use autostash.

Sure, but I don't see that as a big deal. It comes down to the fact that git does (interactive) rebases and some merges in the working tree and not in memory. If it is able to do it in memory, then you also don't need to squash, but it needs a point where it could checkout conflicts, without altering data. If you like it to be automatic, you can always set rebase.autoStash or merge.autoStash.

As for effect on the workflow, you can just continue to work and commit and then call autosquash in two weeks, when your about to merge. This also has the benefit, that Git (by default) only alters commits nobody has used yet.

s/squash/stash/ <<< "then you also don't need to squash"

Ok. JJ wins this round. Go to commit, fix, go to commit is superior to this bunch of commands in every possible way.

That's your opinion.

The second approach has the exact same amount of commands. The first has 2 more. The add is necessary, because Git separates committing into two steps, which has other benefits. If you would want the JJ behaviour you can call commit -a. The autosquash is necessary, because you don't need to use fixup with autosquash, you can also do it alone, which is recommended if this fixes something, that is already in an older release.

Reply on news.ycombinator.com