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

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

Samuel Yvon <samuelyvon9@gmail.com> writes:

>> 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.
>
> Out of curiosity, what would that involve? 

We need to make sure we do not break workflows of existing users who
relies on the current behaviour.  

As Git is widely used, it is very likely that some of the workflow
element existing users use depend on the current behaviour.  

Letting pre-commit do its thing and letting run_status() compute
"commitable" without its effect may be something they depend on.  It
is the same for any other behaviour we may be tempted to modify.  We
would be breaking Git for them by changing.

So, not breaking by not changing behaviour, if we can do so, would
be ideal.  Introducing a configuration option and hide the new and
different behaviour behind it, so that only the folks who agree to
take responsibility of adjusting to the new behaviour, would be a
good way to isolate the existing users from the change.

If we come up with a new behaviour that would make the world a
better place if adopted by everybody, we might be tempted to
eventually make it the _only_ behaviour available to everybody.  I
am not sure if it is the case here, but if it were, the transition
plan would become even more involved.  We'd need to start by warning
existing users (i.e. the code must detect a case where pre-commit
mucks with the index and having an extra "re-read index file" would
have made a difference---and tell the user that they must adjust to
the change of behaviour in the future), wait for a few years and
then flip the behaviour while removing the warning, or something
like that.