user/sven/git.git/cache-tree.c, branch v1.8.0.2

Merge branch 'nd/cache-tree-api-refactor'

2012-02-13T06:42:42Z

* nd/cache-tree-api-refactor: cache-tree: update API to take abitrary flags

Merge branch 'jc/maint-commit-ignore-i-t-a'

2012-02-13T06:42:10Z

* jc/maint-commit-ignore-i-t-a: commit: ignore intent-to-add entries instead of refusing Conflicts: cache-tree.c

cache-tree: update API to take abitrary flags

2012-02-08T00:35:43Z

Signed-off-by: Nguyễn Thái Ngọc Duy Signed-off-by: Junio C Hamano

commit: ignore intent-to-add entries instead of refusing

2012-02-07T20:14:40Z

Originally, "git add -N" was introduced to help users from forgetting to add new files to the index before they ran "git commit -a". As an attempt to help them further so that they do not forget to say "-a", "git commit" to commit the index as-is was taught to error out, reminding the user that they may have forgotten to add the final contents of the paths before running the command. This turned out to be a false "safety" that is useless. If the user made changes to already tracked paths and paths added with "git add -N", and then ran "git add" to register the final contents of the paths added with "git add -N", "git commit" will happily create a commit out of the index, without including the local changes made to the already tracked paths. It was not a useful "safety" measure to prevent "forgetful" mistakes from happening. It turns out that this behaviour is not just a useless false "safety", but actively hurts use cases of "git add -N" that were discovered later and have become popular, namely, to tell Git to be aware of these paths added by "git add -N", so that commands like "git status" and "git diff" would include them in their output, even though the user is not interested in including them in the next commit they are going to make. Fix this ancient UI mistake, and instead make a commit from the index ignoring the paths added by "git add -N" without adding real contents. Based on the work by Nguyễn Thái Ngọc Duy, and helped by injection of sanity from Jonathan Nieder and others on the Git mailing list. Signed-off-by: Junio C Hamano

Refactor cache_tree_update idiom from commit

2011-12-06T22:57:36Z

We'll need to safely create or update the cache-tree data of the_index from other places. While at it, give it an argument that lets us silence the messages produced by unmerged entries (which prevent it from working). Signed-off-by: Thomas Rast Signed-off-by: Junio C Hamano

cache_tree_free: Fix small memory leak

2010-09-07T00:32:28Z

Signed-off-by: Elijah Newren Signed-off-by: Junio C Hamano

write-tree: Avoid leak when index refers to an invalid object

2010-08-11T16:58:38Z

Noticed by valgrind during test t0000.35 “writing this tree without --missing-ok”. Even in the cherry-pick foo..bar code path, such an error is the end of the line. But maybe some day an interactive porcelain will want to link to libgit, making this matter. Signed-off-by: Jonathan Nieder Signed-off-by: Junio C Hamano

Improve on the 'invalid object' error message at commit time

2009-07-14T20:50:33Z

Not that anybody should ever get it, but somebody did (probably because of a flaky filesystem, but whatever). And each time I see an error message that I haven't seen before, I decide that next time it will look better. So this makes us write more relevant information about exactly which file ended up having issues with a missing object. Which will tell whether it was a tree object, for example, or just a regular file in the index (and which one). Signed-off-by: Linus Torvalds Signed-off-by: Junio C Hamano

Optimize "diff-index --cached" using cache-tree

2009-05-25T18:35:29Z

When running "diff-index --cached" after making a change to only a small portion of the index, there is no point unpacking unchanged subtrees into the index recursively, only to find that all entries match anyway. Tweak unpack_trees() logic that is used to read in the tree object to catch the case where the tree entry we are looking at matches the index as a whole by looking at the cache-tree. As an exercise, after modifying a few paths in the kernel tree, here are a few numbers on my Athlon 64X2 3800+: (without patch, hot cache) $ /usr/bin/time git diff --cached --raw :100644 100644 b57e1f5... e69de29... M Makefile :100644 000000 8c86b72... 0000000... D arch/x86/Makefile :000000 100644 0000000... e69de29... A arche 0.07user 0.02system 0:00.09elapsed 102%CPU (0avgtext+0avgdata 0maxresident)k 0inputs+0outputs (0major+9407minor)pagefaults 0swaps (with patch, hot cache) $ /usr/bin/time ../git.git/git-diff --cached --raw :100644 100644 b57e1f5... e69de29... M Makefile :100644 000000 8c86b72... 0000000... D arch/x86/Makefile :000000 100644 0000000... e69de29... A arche 0.02user 0.00system 0:00.02elapsed 103%CPU (0avgtext+0avgdata 0maxresident)k 0inputs+0outputs (0major+2446minor)pagefaults 0swaps Cold cache numbers are very impressive, but it does not matter very much in practice: (without patch, cold cache) $ su root sh -c 'echo 3 >/proc/sys/vm/drop_caches' $ /usr/bin/time git diff --cached --raw :100644 100644 b57e1f5... e69de29... M Makefile :100644 000000 8c86b72... 0000000... D arch/x86/Makefile :000000 100644 0000000... e69de29... A arche 0.06user 0.17system 0:10.26elapsed 2%CPU (0avgtext+0avgdata 0maxresident)k 247032inputs+0outputs (1172major+8237minor)pagefaults 0swaps (with patch, cold cache) $ su root sh -c 'echo 3 >/proc/sys/vm/drop_caches' $ /usr/bin/time ../git.git/git-diff --cached --raw :100644 100644 b57e1f5... e69de29... M Makefile :100644 000000 8c86b72... 0000000... D arch/x86/Makefile :000000 100644 0000000... e69de29... A arche 0.02user 0.01system 0:01.01elapsed 3%CPU (0avgtext+0avgdata 0maxresident)k 18440inputs+0outputs (79major+2369minor)pagefaults 0swaps This of course helps "git status" as well. (without patch, hot cache) $ /usr/bin/time ../git.git/git-status >/dev/null 0.17user 0.18system 0:00.35elapsed 100%CPU (0avgtext+0avgdata 0maxresident)k 0inputs+5336outputs (0major+10970minor)pagefaults 0swaps (with patch, hot cache) $ /usr/bin/time ../git.git/git-status >/dev/null 0.10user 0.16system 0:00.27elapsed 99%CPU (0avgtext+0avgdata 0maxresident)k 0inputs+5336outputs (0major+3921minor)pagefaults 0swaps Signed-off-by: Junio C Hamano

cache-tree.c::cache_tree_find(): simplify internal API

2009-05-25T18:35:19Z

Earlier cache_tree_find() needs to be called with a valid cache_tree, but repeated look-up may find an invalid or missing cache_tree in between. Help simplify the callers by returning NULL to mean "nothing appropriate found" when the input is NULL. Signed-off-by: Junio C Hamano