Re: Should git-prune-script warn about dircache?

From: Junio C Hamano <junkio@cox.net>
Date: May 1, 2005, 20:41 UTC
Message-ID: <7vwtqismpn.fsf@assigned-by-dhcp.cox.net>
In-Reply-To: <7vll6yyiax.fsf@assigned-by-dhcp.cox.net>

>>>>> "JCH" == Junio C Hamano <junkio@cox.net> writes:

>>>>> "LT" == Linus Torvalds <torvalds@osdl.org> writes:

LT> How about making git-prune-script first run "git-update-cache --refresh", LT> and checking the return value of it (this, of course, assumes that LT> git-update-cache --refresh would return non-zero if it can't refresh a LT> file, which is currently not true, but should be easily fixable).

JCH> Or just check if it sees anything in the output, especially JCH> "needs update" line.

Well, we were both wrong. The problem is not about the work tree changes since the last git-update-cache, but about the blobs recorded in the cache but still not committed.

I think we should do something like this.

    git-ls-files --cached | "sed to SHA1 only" | sort >,,1
    git-fsck-cache --unreachable | "sed to SHA1 only" | sort >,,2
    comm -13 ,,1 ,,2 | "sed to .git/object/ path" | xargs -r rm -f