Samuel Yvon <samuelyvon9@xxxxxxxxx> writes: > On one hand, flushing then showing the editor seems to indicate that we want the > editor to be up-to-date, but because the status is prepared before the flushing, > maybe not? > > While it seems the current behaviour has been the behaviour since the start, > I am inclined to continue pushing for this change. Unless I am missing something, > the comment is contradictory and we should be coherent with the idea of > accepting changes made within the pre-commit hook, as noted in > https://lore.kernel.org/git/xmqqk0yripca.fsf@xxxxxxxxxxxxxxxxxxxxxx/t/#u: > >>> Junio C Hamano <gitster@xxxxxxxxx> writes: >>> Even before ec84bd00 (git-commit: Refactor creation of log message., >>> 2008-02-05), the code anticipated that pre-commit may touch the index >>> and tried to cope with it. You seem to be quoting the thread over and over, but what you are quoting is somewhat different from the concluding part of what I said, which was: If I have to guess, I think the reason is because pre-commit automation is expected to be some sort of mechanical change and not part of the actual work that the end-user produced, it would become easier to perform the "final review" of "what have I done so far---does everything make sense?" if such "extra" changes are excluded. So, in short, it is not "undefined", but rather it seems to be a designed behaviour that we are seeing. I do not personally mind if we change the philosophy but because it has been a longstanding designed behaviour, it may need a careful transition plan.
