Johannes Schindelin, Thu, Jun 29, 2006 20:40:46 +0200:
> > >
> > > 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 :)
-
: 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