On Mon, Jan 21, 2013 at 05:45:05PM -0800, Junio C Hamano wrote:
> Duy Nguyen <pclouds@xxxxxxxxx> writes:
>
> > On Tue, Jan 22, 2013 at 6:15 AM, Jeff King <peff@xxxxxxxx> 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
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html