Samuel Yvon <samuelyvon9@xxxxxxxxx> 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.
