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

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

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.

[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 [off-list ref] wrote:

quoted

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.

Hi,

On Thu, 29 Jun 2006, Alex Riesen wrote:

[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 [off-list ref] wrote:

quoted

quoted

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

quoted

:100644 100644 ba41fb96393979b22691106b06bf5231eab57b85

0000000000000000000000000000000000000000 M      N

quoted

whereas git-merge-recursive (and the previous version, without pipe):

.../t/trash$ git-diff-index white
:100644 100644 2d603156dc5bdf6295c789cac08e3c9942a0b82a

0000000000000000000000000000000000000000 M      B

quoted

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.

I think the problem is more like this (in ce_match_stat_basic()):

        if (ce->ce_mtime.sec != htonl(st->st_mtime))
                changed |= MTIME_CHANGED;
        if (ce->ce_ctime.sec != htonl(st->st_ctime))
                changed |= CTIME_CHANGED;

If you update with --index-info, the mtime and ctime is not updated 
from the file in the working directory.

All the more a reason to go forward with direct calls to read_cache() and 
write_cache(). At the moment, my plan is

- trivially split the read_cache() code into read_cache()/read_cache_from(),
- introduce flush_cache(),
- trivially rewrite add_file_to_cache(), and add_cache_info() from
  builtin-update-index.c, move that to read-tree.c, too, and
- throw out the pipe to git-update-index from merge-recursive.c 
  altogether.

This should be less intrusive than it sounds: with the introduction of 
read_cache_from() it should be trivial to handle the problem of different 
index files.

We have to put a lock_file on the index file at the start, and write the 
index file at the end.

Ciao,
Dscho

Johannes Schindelin, Thu, Jun 29, 2006 20:40:46 +0200:

quoted

quoted

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.

I think the problem is more like this (in ce_match_stat_basic()):

        if (ce->ce_mtime.sec != htonl(st->st_mtime))
                changed |= MTIME_CHANGED;
        if (ce->ce_ctime.sec != htonl(st->st_ctime))
                changed |= CTIME_CHANGED;

If you update with --index-info, the mtime and ctime is not updated 
from the file in the working directory.

Oh, I see. I was under impression git-diff-index does not use mtime/ctime.
Thought it was just mode+sha between treeish and index.
    $ man git-diff-index
       git-diff-index <tree-ish>
              compares the <tree-ish> and the files on the filesystem.
       git-diff-index --cached <tree-ish>
              compares the <tree-ish> and the index.
So it does compare treeish ad index, but only if explicitly told so.
Pity, there seem to be no way to update the times in --index-info
protocol yet. Maybe it'll be even never needed, after cache functions
gone libraries.

All the more a reason to go forward with direct calls to read_cache() and 
write_cache(). At the moment, my plan is

- trivially split the read_cache() code into read_cache()/read_cache_from(),
- introduce flush_cache(),
- trivially rewrite add_file_to_cache(), and add_cache_info() from
  builtin-update-index.c, move that to read-tree.c, too, and
- throw out the pipe to git-update-index from merge-recursive.c 
  altogether.

This should be less intrusive than it sounds: with the introduction of 
read_cache_from() it should be trivial to handle the problem of different 
index files.

We have to put a lock_file on the index file at the start, and write the 
index file at the end.

Yes, very nice plan, all by itself :)