Re: Regarding: git-lost+found

From: Junio C Hamano <junkio@cox.net>
Date: Nov 9, 2005, 21:25 UTC
Message-ID: <7vvez1bjjv.fsf@assigned-by-dhcp.cox.net>
In-Reply-To: <Pine.LNX.4.63.0511081811080.18406@wbgn013.biozentrum.uni-wuerzburg.de>

Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:

> I think this is a valuable addition to the "Now what?" part of git. 
> However, I'd like to see the results stored into .git/refs/lost+found/ 
> rather than .git/lost+found/, so that it is possible to inspect them 
> easily with gitk or git-show-branch.

I've thought about it, but on the other hand, having them under refs/ hierarchy means fsck-objects would think they are relevant and prune would never be able to remove them anymore.

The scenario that git-lost+found would be useful is after you did 'git branch -D', 'git tag -d', or 'git tag -f' and removed something you did not mean to by accident. You would find what you want with git-lost+found and perhaps with help from gitk, and then reconnect them. At that point, it is very likely that you would forget to clean the remainder afterwards. Later, you probably forget you have ever run git-lost+found, and would start wondering why git-prune would not remove any leftover anymore.

Maybe we could use .git/lost+found/{commit,other}/?{40} and hang committish under one directory and the rest in another? Then we could do this:

          $ gitk $(cd .git/lost+found/commit && echo ??*)

After you find what you want, you would do 'git tag' or 'git branch' to reconnect them, but we can reasonably expect that is to happen soon after you ran lost+found and before the next time you run prune, because that was why you ran git-lost+found in the first place.

Prune will remove the objects reachable only from lost+found, so the above gitk command line would fail if run after you did git-lost+found and then git-prune in this order, but that is an unlikely sequence.

So, based on the above reasoning, how about this one?

-- >8 -- cut here -- >8 -- [PATCH] lost+found: make it a bit more useful with gitk

This separates the committish from others when resurrecting dangling objects to .git/lost+found/ hierarchy. After running git-lost+found command, you could:

          $ gitk $(cd .git/lost+found/commit && echo ??*)

to see how these branches came about from known old tags.

---

diff --git a/git-lost+found.sh b/git-lost+found.sh
index bc1e988..b6b2616 100755
--- a/git-lost+found.sh
+++ b/git-lost+found.sh
@@ -3,18 +3,21 @@
 . git-sh-setup || die "Not a git archive."
 
 laf="$GIT_DIR/lost+found"
-mkdir -p "$laf" || exit
+rm -fr "$laf" && mkdir -p "$laf/commit" "$laf/other" || exit
 
 git fsck-objects |
 while read dangling type sha1
 do
 	case "$dangling" in
 	dangling)
-		echo "$sha1" >"$laf/$sha1"
-		case "$type" in
-		commit | tag)
-			git-show-branch "$sha1" ;;
-		esac
+		if git-rev-parse --verify "$sha1^0" >/dev/null 2>/dev/null
+		then
+			dir="$laf/commit"
+			git-show-branch "$sha1"
+		else
+			dir="$laf/other"
+		fi
+		echo "$sha1" >"$dir/$sha1"
 		;;
 	esac
 done