Re: [RFC PATCH v3 8/8] --sparse for porcelains

[Nguyen Thai Ngoc Duy <pclouds@gmail.com>]

On Mon, Aug 17, 2009 at 10:41 PM, Junio C Hamano<gitster@pobox.com> wrote:
> How should assume-unchanged play with this philosophy?
>
> I'd say that assume-unchanged is a promise you make git that you won't
> change these paths, and in return to the promise git will give you faster
> response by not running lstat on them.  Having changes in such paths is
> your problem and you deserve these chanegs to be lost.  At least, that is
> the interpretation according to the original assume-unchanged semantics.

But commit 5f73076 ("Assume unchanged" git) says [1] it favors safety
over performance? Otherwise I'd need to resurrect no-checkout bit.

[1] excerpt from the mentioned commit:
--<--
    Index entries marked with CE_VALID bit are assumed to be
    unchanged most of the time.  However, there are cases that
    CE_VALID bit is ignored for the sake of safety and usability:

     - while "git-read-tree -m" or git-apply need to make sure
       that the paths involved in the merge do not have local
       modifications.  This sacrifices performance for safety.

     - when git-checkout-index -f -q -u -a tries to see if it needs
       to checkout the paths.  Otherwise you can never check
       anything out ;-).

     - when git-update-index --really-refresh (a new flag) tries to
       see if the index entry is up to date.  You can start with
       everything marked as CE_VALID and run this once to drop
       CE_VALID bit for paths that are modified.
--<--
-- 
Duy