]> git.ipfire.org Git - thirdparty/git.git/commit - config.c
"Assume unchanged" git
authorJunio C Hamano <junkio@cox.net>
Thu, 9 Feb 2006 05:15:24 +0000 (21:15 -0800)
committerJunio C Hamano <junkio@cox.net>
Thu, 9 Feb 2006 05:54:42 +0000 (21:54 -0800)
commit5f73076c1a9b4b8dc94f77eac98eb558d25e33c0
treea8fb724d3529975a15e2e35bb04da1b90a52f4da
parentd19e06fa8f86b611c10115903ef7e50d5de112f0
"Assume unchanged" git

This adds "assume unchanged" logic, started by this message in the list
discussion recently:

<Pine.LNX.4.64.0601311807470.7301@g5.osdl.org>

This is a workaround for filesystems that do not have lstat()
that is quick enough for the index mechanism to take advantage
of.  On the paths marked as "assumed to be unchanged", the user
needs to explicitly use update-index to register the object name
to be in the next commit.

You can use two new options to update-index to set and reset the
CE_VALID bit:

git-update-index --assume-unchanged path...
git-update-index --no-assume-unchanged path...

These forms manipulate only the CE_VALID bit; it does not change
the object name recorded in the index file.  Nor they add a new
entry to the index.

When the configuration variable "core.ignorestat = true" is set,
the index entries are marked with CE_VALID bit automatically
after:

 - update-index to explicitly register the current object name to the
   index file.

 - when update-index --refresh finds the path to be up-to-date.

 - when tools like read-tree -u and apply --index update the working
   tree file and register the current object name to the index file.

The flag is dropped upon read-tree that does not check out the index
entry.  This happens regardless of the core.ignorestat settings.

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.

Most notably, "update-index --refresh" honours CE_VALID and does
not actively stat, so after you modified a file in the working
tree, update-index --refresh would not notice until you tell the
index about it with "git-update-index path" or "git-update-index
--no-assume-unchanged path".

This version is not expected to be perfect.  I think diff
between index and/or tree and working files may need some
adjustment, and there probably needs other cases we should
automatically unmark paths that are marked to be CE_VALID.

But the basics seem to work, and ready to be tested by people
who asked for this feature.

Signed-off-by: Junio C Hamano <junkio@cox.net>
13 files changed:
apply.c
cache.h
checkout-index.c
config.c
diff-files.c
diff-index.c
diff.c
entry.c
environment.c
read-cache.c
read-tree.c
update-index.c
write-tree.c