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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Tue, Jan 8, 2019 at 4:44 PM Duy Nguyen <pclouds@xxxxxxxxx> wrote:
>
> On Tue, Jan 8, 2019 at 2:28 PM Anthony Sottile <asottile@xxxxxxxxx> 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



[Index of Archives]     [Linux Kernel Development]     [Gcc Help]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [V4L]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Fedora Users]

  Powered by Linux