Re: Destructive pre-commit behaviour and "--all"

On Wed, Mar 22, 2023 at 3:35 AM Jan Rüegg <rggjan@gmail.com> wrote:

It's not completely clear to me what behavior you *want* here, but I can answer the "why doesn't" question.

Remember that `git commit` can be aborted (in several ways). If it *is* aborted, whatever it did must be rolled back. This means that `git commit -a`, which is otherwise a lot like `git add -u && git commit`, is fundamentally different from a successful `git add -u` followed by a `git commit`. In particular, if the `git commit` *is* aborted, the `git commit -a` command *must not* leave the updated files in the index. The `git commit` without `-a` did not update any files in the index, so it does not have to "roll back" the index update.

To achieve this, `git commit -a` doesn't actually update *the* index at all. Instead, it prepares a *new* index and updates that new index. It then proceeds to do the committing, using the new index, rather than the main index, as if it were *the* index. If all goes well so that the commit is done, the code then swaps in the *new* index for *the* index. If the commit is aborted, the code simply *deletes* the new index, leaving *the* index unchanged.

This is fundamentally different from "update *the* index, then start committing, then either roll back *the* index or leave it in place": there's a secondary temporary index involved here.

Things get even more complicated if you use `git commit --only` (vs `git commit --include`) as in this case there are *three* indices simultaneously active ("the" index, "proposed index for commit", and "proposed index if commit succeeds"). All three must be managed carefully and correctly.

It is unwise to invoke `git add` in a pre-commit hook precisely because there may be two or three indices, and `git add` cannot affect all of them correctly.

Note that Git could be designed differently (with real databases that have roll-forward and roll-back options), but that's a much bigger change. The process described here is merely how Git works now, which explains the constraints on using `git add` in pre- commit hooks.

Chris