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

[Chris Torek <chris.torek@gmail.com>]

On Wed, Mar 22, 2023 at 1:00 PM Chris Torek <chris.torek@gmail.com> wrote:
[snip]
> 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. ...

I realized on re-reading my reply here that there's an odd bit at
the end.  It's because I decided to simplify something away, but
that left the oddness: bigger change than what?  So I'll bring the
extra part back in.

For a `git commit` *without* `-a`, Git has a special case: after
it runs the pre-commit hook, it reloads *the* index, as there's
only the one index.  This makes it possible to run `git add`
successfully in a pre-commit hook.  But when using `--only`,
`--include`, or `--all` / `-a`, there are multiple index files.
Git therefore *doesn't* re-load "the" index.

It would in theory be possible for Git to load *the* index twice,
once before and once after the hook, and compare them to see what
changed, then perhaps try to use that change to update the
additional indices.  That would be a pretty big change, but if it
were done right, it might get what you want.

Chris