• Junio C Hamano's avatar
    Make ce_uptodate() trustworthy again · 125fd984
    Junio C Hamano authored
    The rule has always been that a cache entry that is ce_uptodate(ce)
    means that we already have checked the work tree entity and we know
    there is no change in the work tree compared to the index, and nobody
    should have to double check.  Note that false ce_uptodate(ce) does not
    mean it is known to be dirty---it only means we don't know if it is
    clean.
    
    There are a few codepaths (refresh-index and preload-index are among
    them) that mark a cache entry as up-to-date based solely on the return
    value from ie_match_stat(); this function uses lstat() to see if the
    work tree entity has been touched, and for a submodule entry, if its
    HEAD points at the same commit as the commit recorded in the index of
    the superproject (a submodule that is not even cloned is considered
    clean).
    
    A submodule is no longer considered unmodified merely because its HEAD
    matches the index of the superproject these days, in order to prevent
    people from forgetting to commit in the submodule and updating the
    superproject index with the new submodule commit, before commiting the
    state in the superproject.  However, the patch to do so didn't update
    the codepath that marks cache entries up-to-date based on the updated
    definition and instead worked it around by saying "we don't trust the
    return value of ce_uptodate() for submodules."
    
    This makes ce_uptodate() trustworthy again by not marking submodule
    entries up-to-date.
    
    The next step _could_ be to introduce a few "in-core" flag bits to
    cache_entry structure to record "this entry is _known_ to be dirty",
    call is_submodule_modified() from ie_match_stat(), and use these new
    bits to avoid running this rather expensive check more than once, but
    that can be a separate patch.
    Signed-off-by: default avatarJunio C Hamano <gitster@pobox.com>
    125fd984
preload-index.c 2.3 KB