Hi, On Mon, 12 Aug 2019, Phillip Wood wrote: > On 12/08/2019 18:50, SZEDER Gábor wrote: > > > > When running interactive rebase to reword a commit message, I would > > expect that the commit whose message I'm rewording is checked out. > > This is not quite the case when rewording multiple subsequent commit > > messages. > > > > Let's start with four commits, and start an interactive rebase from > > the first commit: > > > > $ git log --oneline > > 5835aa1 (HEAD -> master) fourth > > 64ecc64 third > > d5fad83 second > > 384b86f first > > $ git rebase -i 384b86f > > > > Update the instruction sheet to edit the log messages of two > > subsequent commits: > > > > r d5fad83 second > > r 64ecc64 third > > pick 5835aa1 fourth > > > > Now, after the editor opens up the second commit's log message, start > > a new terminal and check where HEAD is pointing to: > > > > ~/tmp/reword (master|REBASE-i 1/3)$ head -n1 .git/COMMIT_EDITMSG > > second > > ~/tmp/reword (master|REBASE-i 1/3)$ git log --oneline -1 > > d5fad83 (HEAD) second > > > > So far so good. > > Because the sequencer can fast-forwarded to second from first it does that and > then run 'commit --amend' to do the reword. > > > Save the updated commit message, and after the editor opens up the > > third commit's log message, check again where HEAD is pointing to now: > > > > ~/tmp/reword (master +|REBASE-i 2/3)$ head -n1 .git/COMMIT_EDITMSG > > third > > ~/tmp/reword (master +|REBASE-i 2/3)$ git log --oneline -1 > > c3db735 (HEAD) second - updated > > As second has been updated the sequencer cannot fast-forward to third so it > cherry-picks third and then passes --edit when it runs 'git commit' to commit > the cherry-pick. HEAD is updated once the reworded commit has been created. > > I think the scripted rebase always ran cherry-pick and then ran 'commit > --amend' afterwards if the commit was being reworded. The C implementation is > more efficient as it avoids creating an redundant commit but has the side > effect that HEAD is not updated before the reword which was surprising here. Indeed, that was even intentional. > I don't think I've ever looked at HEAD while rewording, my shell prompt gets > the current pick from .git/rebase-merge/done so does not look at HEAD. While > it might seem odd if the user looks at HEAD it's quite nice not to create a > new commit only to amend it straight away when it's reworded. We have > REBASE_HEAD which always points to the current pick - HEAD is also an > unreliable indicator of the current pick if there are conflicts. That is interesting; I would never have thought about scripting around `reword`. However, I am reluctant to accept the performance impact: in the long run, I would love to have an interactive rebase that actually only updates `HEAD` (and the worktree) when interrupting the rebase (via `break` or `edit`), and `reword` does not qualify for "interrupting" in my mind. Ciao, Dscho
