Re: [PATCH/RFC] commit: new option to abort -a something is already staged

From: Junio C Hamano <gitster@pobox.com>
Date: Aug 23, 2018, 15:28 UTC
Message-ID: <xmqqr2ipje5i.fsf@gitster-ct.c.googlers.com>
In-Reply-To: <CACsJy8DdZLxdA4XSVVBSpeZaF+q6=81LxecYea2JtJ6-Krnk-A@mail.gmail.com>

Duy Nguyen <pclouds@gmail.com> writes:

Show 16 quoted lines

> On Thu, Aug 23, 2018 at 4:15 AM Jonathan Nieder <jrnieder@gmail.com> wrote:
>> > The remaining question becomes scripts.  A script might do
>> >
>> >       ... modify old-file and create new-file ...
>> >       git add new-file
>> >       git commit -m "some great message"
>> >
>> > which would trip this error.  For that matter, humans might do that,
>> > too.  Could the check detect this case (where the only changes in the
>> > index are additions of new files) and treat it as non-destructive?
>>
>> (where the only changes in the index are additions of new files *that
>> match the worktree*)
>
> I don't think my change would affect this case. If "git commit" does
> not change the index by itself, there's no point in stopping it.

I think the above example forgets "-a" on the final "git commit" step. With it added, I can understand the concern (and I am sure you would, too).

The user is trying to add everything done in the working tree, and "commit -a" would catch all changes to paths that were already tracked, but a separate "add" is necessary for newly created paths. But adding a new path means the index no longer matches HEAD, and the "commit -a" at the final step sweeps the changes to already tracked paths---failing that because there "already is something staged" will break the workflow.