Re: `git reset` for delete + intent-to-add doesn't reset

From: Duy Nguyen <pclouds@gmail.com>
Date: Jan 8, 2019, 10:06 UTC
Message-ID: <CACsJy8Bov1asw+_J_fbhKqigM==xNPi8itDGkhibkYVch4pvmQ@mail.gmail.com>
In-Reply-To: <CACsJy8Atwp1nQbDaxYSNiDFmVmMG2h88w=dAZWU1SF6JQ18EEw@mail.gmail.com>

On Tue, Jan 8, 2019 at 4:44 PM Duy Nguyen <pclouds@gmail.com> wrote:

Show 18 quoted lines

>
> On Tue, Jan 8, 2019 at 2:28 PM Anthony Sottile <asottile@umich.edu> wrote:
> >
> > ```
> > git --version
> > rm -rf t
> > git init t
> > cd t
> > touch a
> > git add a
> > git commit -m "add a"
> > git rm a
> > touch a
> > git add --intent-to-add a
> > git status --short
> > git reset -- a
>
> "git reset" without "-- a" does remove intent-to-add status.

No I'm wrong. But it was because I didn't follow your exact steps.

This is quite unique corner case. What happens is "git reset" internally does "git diff --cached" basically to see what paths need to update, then reset those paths and as a side effect, intent-to-add status will be removed. But in this case, "a" in HEAD has empty content, exactly the same content represented by an intent-to-add entry. So "git diff --cached" decides there's no changes in "a", no need to update it (so i-t-a status remains).

This can only happen if a file in HEAD is empty, which is quite unlikely. This fix could be go through the index list the second time just for resetting i-t-a status, but I'm not sure if it's worth doing.

-- 
Duy