On Wed, Mar 22, 2023 at 3:35 AM Jan Rüegg <rggjan@xxxxxxxxx> wrote:
> Why doesn't "git commit --all" keep the files added to the staging
> area, so "git commit --all" would have the same behaviour as "git add
> --all && git commit"?
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
