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 <junkio@xxxxxxx> wrote: > > > 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. 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 - : 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