Re: Regarding: git-lost+found

Johannes Schindelin [off-list ref] 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