Re: [RFC PATCH v3 8/8] --sparse for porcelains
- From
Nguyen Thai Ngoc Duy <pclouds@gmail.com>
- Date
- Aug 17, 2009, 16:06 UTC
- Message-ID
- <fcaeb9bf0908170906m739be4abs80ee3a6fc7135fbd@mail.gmail.com>
- In-Reply-To
- <7vtz06xxao.fsf@alter.siamese.dyndns.org>
On Mon, Aug 17, 2009 at 10:41 PM, Junio C Hamano<gitster@pobox.com> wrote:
Show 7 quoted lines
> 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