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

From: Alex Riesen <raa.lkml@gmail.com>
Date: Jun 29, 2006, 08:43 UTC
Message-ID: <81b0412b0606290143g5a3a0f5atbda3f4250411e92e@mail.gmail.com>
In-Reply-To: <7vzmfwy97w.fsf@assigned-by-dhcp.cox.net>

[cc list restored, I'm lost in the maze of git update-index, all cache changing functions looking almost the same]

On 6/29/06, Junio C Hamano <junkio@cox.net> wrote:

Show 22 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.

Ok. Am I correct in the assumption, that if the file in working tree has the same SHA1 as LHS, than the next "git-update-index --refresh" will remove the entry from git-diff-index output? This is what actually happens, if I do "git-update-index --refresh", so I suspect that I have an SHA1 update gone missing somewhere.