[PATCH] Git-prune-script loses blobs referenced from an uncommitted cache.

[PATCH] Git-prune-script loses blobs referenced from an uncommitted cache.

[Junio C Hamano]

When a new blob is registered with update-cache, and before the cache
is written as a tree and committed, git-fsck-cache will find the blob
unreachable.  This patch fixes git-prune-script to keep such blob objects
referenced from the cache.

Without this fix, "diff-cache -p --cached" after git-prune-script has
pruned the blob object will fail mysteriously and git-write-tree would
also fail.

Signed-off-by: Junio C Hamano <junkio@cox.net>
---

git-prune-script |   32 +++++++++++++++++++++++++++++++-
1 files changed, 31 insertions(+), 1 deletion(-)

--- a/git-prune-script
+++ b/git-prune-script
@@ -1,2 +1,32 @@
 #!/bin/sh
-git-fsck-cache --unreachable $(cat .git/HEAD ) | grep unreachable | cut -d' ' -f3 | sed 's:^\(..\):.git/objects/\1/:' | xargs rm
+
+tmp=.git-prune-script-$$
+trap "rm -f $tmp-*" 0 1 2 3 15 
+
+# Defaulting to include .git/refs/*/* may be debatable from the
+# purist POV but power users can always give explicit parameters
+# to the script anyway.
+case "$#" in
+0) set x $(cat .git/HEAD .git/refs/*/*); shift ;;
+esac
+
+git-fsck-cache --unreachable "$@" |
+sed -ne 's/unreachable [^ ][^ ]* //p' |
+sort >$tmp-unreachable
+
+# This makes extra objects to be kept if the cache has an entry
+# with an unusual name like "this\n0 0123...abcdef 0 file", but
+# we are trying not to discard information and keeping extra in
+# an unusual situation would be OK.
+git-ls-files --stage |
+sed -ne 's|^[0-7][0-7]* \([0-9a-f][0-9a-f]*\) [0-3] .*|\1|p' |
+sort >$tmp-keep
+
+comm -23 $tmp-unreachable $tmp-keep |
+sed -e 's|\(..\)|\1/|' | {
+	case "$SHA1_FILE_DIRECTORY" in
+	'') cd .git/objects/ ;;
+	*) cd "$SHA1_FILE_DIRECTORY" ;;
+	esac || exit
+	xargs -r echo rm -f
+}

Re: [PATCH] Git-prune-script loses blobs referenced from an uncommitted cache.

[Linus Torvalds]

On Mon, 2 May 2005, Junio C Hamano wrote:
>
> When a new blob is registered with update-cache, and before the cache
> is written as a tree and committed, git-fsck-cache will find the blob
> unreachable.  This patch fixes git-prune-script to keep such blob objects
> referenced from the cache.

Actually, I'd almost rather just have git-fsck-cache actually do a
"read_cache()" and walk through that and marking the sha1's as "needed".

That's useful for another reason: not only does it mean that we don't drop 
objects that may be in the current index, but it _also_ means that we 
check that the current index actually has everything that it needs. I had 
that situation a few times after I did a "convert-cache" - where I had an 
old index file that pointed to the old objects _before_ the conversion.

I noticed it the hard way, and happily it's easily fixed by just doing a 
"git-read-cache <new-head>", but it was actually very confusing when it 
happened, and it would have been good to have fsck-cache warn about it.

		Linus