On Mon, Aug 12, 2019 at 11:17:01AM -0700, Junio C Hamano wrote: > SZEDER Gábor <szeder.dev@xxxxxxxxx> writes: > > > ... > > So far so good. > > 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 you can see, HEAD still points to the (now rewritten) second > > commit. > > > > It's only HEAD,... > > Yuck. > > That would still be annoying to some people and outright buggy to > others, if their workflow relies on HEAD (e.g. compare with HEAD > while reviewing the log messsage) and then now they instead need to > adjust (e.g. compare with the index instead). Well, it's caused by a 2.5 year old commit, so either all those people have been lucky so far (or just don't do subsequent rewords?), or those who stumbled upon it already adjusted without complaining to us. > Perhaps you are one of them No; during the second reword I ran 'git log -2' in the other terminal (wanted to copy a sentence from the previous, just reworded commit), and noticed that the two listed commits were "off by one". BTW, rewriting the first commit appears to be important. When doing an edit-reword of two subsequent commits, then this issue only happens if the edit actually rewrites the commit. However, when, instead of editing anything, I do a 'git rebase --continue' right away, then HEAD points to where it should during the subsequent reword. Anyway, Cc:-ing Dscho for his rebase expertise.
