Re: [PATCH v2] unpack-trees: do not abort when overwriting an existing file with the same content

From: Junio C Hamano <gitster@pobox.com>
Date: Jan 22, 2013, 01:45 UTC
Message-ID: <7vwqv6c7oe.fsf@alter.siamese.dyndns.org>
In-Reply-To: <CACsJy8AFKXYkHbUf4aqBpCg+v06oFsvHq_zxQFE4BOCzTDAqtg@mail.gmail.com>

Duy Nguyen <pclouds@gmail.com> writes:

Show 8 quoted lines

> On Tue, Jan 22, 2013 at 6:15 AM, Jeff King <peff@peff.net> wrote:
>> Can you elaborate on when this code is triggered?
>>
>> In the general case, shouldn't we already know the sha1 of what's on
>> disk in the index, and be able to just compare the hashes? And if we
>> don't, because the entry is start-dirty, should we be updating it
>> (possibly earlier, so we do not even get into the "need to write" code
>> path) instead of doing this ad-hoc byte comparison?

If the index knows what is in the working tree, I think I agree.

Show 7 quoted lines

>> Confused...
>
> git reset HEAD~10
> # blah that was a mistake, undo it
> git checkout HEAD@{1}
>
> I hit it a few times, probably not with the exact recipe above though.

I've seen myself doing "git reset HEAD~10" by mistake (I wanted "--hard"), but the recovery is to do "git reset --hard @{1}" and then come back with "git reset --hard HEAD~10", so it hasn't been a real problem for me.

A case similar to this is already covered by a special case of two-tree read-tree where the index already matches the tree we are checking out even though it is different from HEAD; in other words, if you did this:

        git init
        date >file
        git add file; git commit -m 'has a file'
        git checkout -b side
        git rm file; git commit -m 'does not have the file'
        git checkout master file
	: now index has the file from 'master' and worktree is clean
        git checkout master

you shouldn't get any complaint, I think.

If you did "git rm --cached file" to lose it from the index, immediately after "git checkout master file", then we wouldn't know what we may be losing. If the file in the working tree happens to match the index and the HEAD after checking out the other branch ('master' in this case), it is _not_ losing information, so we might be able to treat it as an extension of the existing special case.

I haven't thought things through to see if in a more general case that this codepath triggers we might be losing a local changes that we should be carrying forward while checking out a new branch, though.