Re: [PATCH] builtin-commit: re-read file index before launching editor

[Junio C Hamano <gitster@pobox.com>]

Samuel Yvon <samuelyvon9@gmail.com> 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@gitster.c.googlers.com/t/#u:
>
>>> Junio C Hamano <gitster@pobox.com> 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.