From: Nguyen Thai Ngoc Duy Date: Mon, 17 Aug 2009 16:06:00 GMT Subject: Re: [RFC PATCH v3 8/8] --sparse for porcelains Message-ID: In-Reply-To: <7vtz06xxao.fsf@alter.siamese.dyndns.org> On Mon, Aug 17, 2009 at 10:41 PM, Junio C Hamano 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