Teach gitlinks to ie_modified() and ce_modified_check_fs()
authorJunio C Hamano <gitster@pobox.com>
Tue, 29 Jul 2008 08:13:44 +0000 (01:13 -0700)
committerJunio C Hamano <gitster@pobox.com>
Wed, 30 Jul 2008 07:09:22 +0000 (00:09 -0700)
commitc70115b4b1a8c197b9b829b1fd15d578a3ffcdc3
tree9f4558d573cf7cf7c415f935dfd07964ac57322d
parentbd2574ca69331d33429f8806ce189b2941e490e7
Teach gitlinks to ie_modified() and ce_modified_check_fs()

The ie_modified() function is the workhorse for refresh_cache_entry(),
i.e. checking if an index entry that is stat-dirty actually has changes.

After running quicker check to compare cached stat information with
results from the latest lstat(2) to answer "has modification" early, the
code goes on to check if there really is a change by comparing the staged
data with what is on the filesystem by asking ce_modified_check_fs().
However, this function always said "no change" for any gitlinks that has a
directory at the corresponding path.  This made ie_modified() to miss
actual changes in the subproject.

The patch fixes this first by modifying an existing short-circuit logic
before calling the ce_modified_check_fs() function.  It knows that for any
filesystem entity to which ie_match_stat() says its data has changed, if
its cached size is nonzero then the contents cannot match, which is a
correct optimization only for blob objects.  We teach gitlink objects to
this special case, as we already know that any gitlink that
ie_match_stat() says is modified is indeed modified at this point in the
codepath.

With the above change, we could leave ce_modified_check_fs() broken, but
it also futureproofs the code by teaching it to use ce_compare_gitlink(),
instead of assuming (incorrectly) that any directory is unchanged.

Originally noticed by Alex Riesen on Cygwin.

Signed-off-by: Junio C Hamano <gitster@pobox.com>
read-cache.c