Re: CFT: merge-recursive in C (updated)

From: Junio C Hamano <junkio@cox.net>
Date: Jun 29, 2006, 02:41 UTC
Message-ID: <7vzmfwy97w.fsf@assigned-by-dhcp.cox.net>
In-Reply-To: <20060629002547.GA27507@steel.home>

fork0@t-online.de (Alex Riesen) writes:

Show 15 quoted lines

> this broke t6022-merge-rename.sh (the second test). It produces an
> index with this:
>
> .../t/trash$ git-diff-index white
> :100644 100644 2d603156dc5bdf6295c789cac08e3c9942a0b82a 0000000000000000000000000000000000000000 M      B
> :100644 100644 ba41fb96393979b22691106b06bf5231eab57b85 0000000000000000000000000000000000000000 M      N
>
> whereas git-merge-recursive (and the previous version, without pipe):
>
> .../t/trash$ git-diff-index white
> :100644 100644 2d603156dc5bdf6295c789cac08e3c9942a0b82a 0000000000000000000000000000000000000000 M      B
>
> I can see that "git update-index --add" is somehow different from a
> pipe to "git update-index --index-info", but not very clear. Does this
> "zero-sha1" mean that the file "N" is not in the index?

When diff-index and diff-files compare a tree entry or an index entry with a file in the working tree, they do not compute the blob hash value for the file in the working tree. 0{40} is used on the RHS in such a case. When the working tree file matches the corresponding index entry, then we know RHS matches what is in the index, so both sides have the blob hash value.