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

From: Jeff King <peff@peff.net>
Date: Jan 22, 2013, 20:19 UTC
Message-ID: <20130122201929.GB23521@sigill.intra.peff.net>
In-Reply-To: <7vwqv6c7oe.fsf@alter.siamese.dyndns.org>

On Mon, Jan 21, 2013 at 05:45:05PM -0800, Junio C Hamano wrote:

Show 12 quoted lines

> Duy Nguyen <pclouds@gmail.com> writes:
> 
> > 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.

Right. I was wondering why it didn't (and if it doesn't, why we are not saving the information there).

But I think I was letting my inaccurate mental model of the index get in the way. I tend to think of the stat information as "if the file matches this stat info, then it has sha1 X". But that is not true. The sha1 we store is the actual index entry, and if it does not match what is in the working tree, we do not know or store the sha1 of what is in the working tree. We cannot just "refresh" that value and compare it, which is what I was implying.

So I think I was just confused. That is what I get for not actually doing low-level index stuff enough.

> > git reset HEAD~10
> > # blah that was a mistake, undo it
> > git checkout HEAD@{1}

It seems like

  git reset HEAD@{1}

would be the correct undo, as the original never touched the working tree.

-Peff