Regarding: git-lost+found

Regarding: git-lost+found

[Johannes Schindelin]

Hi,

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.

Just my sue tents,
Dscho

Re: Regarding: git-lost+found

[Petr Baudis]

Dear diary, on Tue, Nov 08, 2005 at 06:13:06PM CET, I got a letter
where Johannes Schindelin <Johannes.Schindelin@gmx.de> told me that...
> 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.

What is it supposed to be?

-- 
				Petr "Pasky" Baudis
Stuff: http://pasky.or.cz/
VI has two modes: the one in which it beeps and the one in which
it doesn't.

Re: Regarding: git-lost+found

[Petr Baudis]

> > 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.
> 
> What is it supposed to be?

Sorry for the noise - /lost.found/ found some matches (see the "what
after 0.98" mail from Junio). (Still, it would be helpful to put a
reference to your mail.)

-- 
				Petr "Pasky" Baudis
Stuff: http://pasky.or.cz/
VI has two modes: the one in which it beeps and the one in which
it doesn't.

Re: Regarding: git-lost+found

[Junio C Hamano]

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

Re: Regarding: git-lost+found

[Daniel Barkalow]

On Wed, 9 Nov 2005, Junio C Hamano wrote:

> 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.

Why have git-lost+found write to files at all? It seems to me easiest to 
have the list go to standard out, and you could do "gitk `git-lost+found 
-t commit`" to see lost commits, and reconnect them as desired. (Making up 
command line syntax for listing only the commits.)

	-Daniel
*This .sig left intentionally blank*

Re: Regarding: git-lost+found

[Junio C Hamano]

Daniel Barkalow <barkalow@iabervon.org> writes:

> Why have git-lost+found write to files at all? It seems to me easiest to 
> have the list go to standard out, and you could do "gitk `git-lost+found 
> -t commit`" to see lost commits, and reconnect them as desired. (Making up 
> command line syntax for listing only the commits.)

That is certainly cleaner.  The only downside is fsck-objects
that lost+found uses tends to be expensive operation, and what
you would want to do with the information may be more than just
use it on the command line of gitk.  But in any case the user
could store git-lost+found output in a file to do whatever she
wants, so it may not matter.

Re: Regarding: git-lost+found

[Daniel Barkalow]

On Wed, 9 Nov 2005, Junio C Hamano wrote:

> Daniel Barkalow <barkalow@iabervon.org> writes:
> 
> > Why have git-lost+found write to files at all? It seems to me easiest to 
> > have the list go to standard out, and you could do "gitk `git-lost+found 
> > -t commit`" to see lost commits, and reconnect them as desired. (Making up 
> > command line syntax for listing only the commits.)
> 
> That is certainly cleaner.  The only downside is fsck-objects
> that lost+found uses tends to be expensive operation, and what
> you would want to do with the information may be more than just
> use it on the command line of gitk.  But in any case the user
> could store git-lost+found output in a file to do whatever she
> wants, so it may not matter.

Actually, my next suggestion would be to have gitk able to write 
hashes as refs, so that, having put it on the gitk command line, you could 
then do the things you want from there.

	-Daniel
*This .sig left intentionally blank*

Re: Regarding: git-lost+found

[Matthias Urlichs]

Hi, Junio C Hamano wrote:

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

Along those lines... I just tried that, it found a whole heap of old
commits I didn't yet clean up, and they're sorted by their SHA1.

In other words, actually finding the latest commit in there was a
nontrivial task.

I don't speak tcl, so could somebody please change "gitk -d" to sort its
command line by date (newest first, of course)?  Thanks.

-- 
Matthias Urlichs   |   {M:U} IT Design @ m-u-it.de   |  smurf@smurf.noris.de
Disclaimer: The quote was selected randomly. Really. | http://smurf.noris.de
 - -
Innocence ends when one is stripped of the delusion that one likes
oneself.

Fix git-rev-list "date order" with --topo-order

[Linus Torvalds]

This fixes git-rev-list so that when there are multiple branches, we still 
sort the heads in proper approximate date order even when sorting the 
output topologically.

This makes things like

	gitk --all -d

work sanely and show the branches in date order (where "date order" is 
obviously modified by the paren-child dependency requirements of the 
topological sort).

The trivial fix is to just build the "work" list in date order rather than 
inserting the new work entries at the beginning.

Signed-off-by: Linus Torvalds <torvalds@osdl.org>
---

This should also fix this report, although Matthias should double-test..

On Mon, 14 Nov 2005, Matthias Urlichs wrote:
> 
> >           $ gitk $(cd .git/lost+found/commit && echo ??*)
> 
> Along those lines... I just tried that, it found a whole heap of old
> commits I didn't yet clean up, and they're sorted by their SHA1.
> 
> In other words, actually finding the latest commit in there was a
> nontrivial task.
> 
> I don't speak tcl, so could somebody please change "gitk -d" to sort its
> command line by date (newest first, of course)?  Thanks.

diff --git a/commit.c b/commit.c
index 534c03e..ebf4db6 100644
--- a/commit.c
+++ b/commit.c
@@ -536,7 +536,7 @@ int count_parents(struct commit * commit
 void sort_in_topological_order(struct commit_list ** list)
 {
 	struct commit_list * next = *list;
-	struct commit_list * work = NULL;
+	struct commit_list * work = NULL, **insert;
 	struct commit_list ** pptr = list;
 	struct sort_node * nodes;
 	struct sort_node * next_nodes;
@@ -580,11 +580,12 @@ void sort_in_topological_order(struct co
          * the tips serve as a starting set for the work queue.
          */
 	next=*list;
+	insert = &work;
 	while (next) {
 		struct sort_node * node = (struct sort_node *)next->item->object.util;
 
 		if (node->indegree == 0) {
-			commit_list_insert(next->item, &work);
+			insert = &commit_list_insert(next->item, insert)->next;
 		}
 		next=next->next;
 	}