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

From: Duy Nguyen <pclouds@gmail.com>
Date: Aug 24, 2018, 14:42 UTC
Message-ID: <CACsJy8AenCeoEmEZbYwgAA_U53D1cPXC1Ob7G-6MsoGQ_U2D0Q@mail.gmail.com>
In-Reply-To: <CA+P7+xq3m8PXo9wYu1L7p4uG4hf-i=uwQdh+e=0QJXG1cBi04A@mail.gmail.com>

On Fri, Aug 24, 2018 at 5:02 AM Jacob Keller <jacob.keller@gmail.com> wrote:

Show 16 quoted lines

>
> On Thu, Aug 23, 2018 at 9:28 AM Junio C Hamano <gitster@pobox.com> wrote:
> > 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.
>
> Right. I think this would need to be able to understand the case of
> "different only by new files".

OK so the rules I'm going to try to implement is, if the version in the index is not the same as one in HEAD or one in worktree, then "git commit -a" fails.

The unwritten line is, if the path in question does not exist in HEAD, then the first condition "as one in HEAD" is dropped, naturally. This addresses the "git add new-file" problem, but if you have made more changes in new-file in worktree after "git add" and do "git commit -a" then you still get rejected because it fails the second condition.

File removal should be considered as well. But I don't foresee any problem there. Resolving merges, replacing higher stage entries with stage 0 will be accepted at "git commit -a" as usual.

Let me know if we should tweak these rules (and how).

-- 
Duy