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

From: Chris Torek <chris.torek@gmail.com>
Date: Mar 22, 2023, 21:26 UTC
Message-ID: <CAPx1GvfFrUQBDnJ9QYue91ScZb9ctB+tWv2S+pcprVC7dTgdxg@mail.gmail.com>
In-Reply-To: <CAPx1GvftGM2kpVL9JWWXrjyTRWs+6OxteoJDq9dgeOjuidUGwg@mail.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