Johannes SchindelinHi,
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
Petr BaudisRe: Regarding: git-lost+found
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.
Petr BaudisRe: Regarding: git-lost+found
> > 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.
Junio C HamanoRe: Regarding: git-lost+found
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
Daniel BarkalowRe: Regarding: git-lost+found
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*
Junio C HamanoRe: Regarding: git-lost+found
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.
Daniel BarkalowRe: Regarding: git-lost+found
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*
Matthias UrlichsRe: Regarding: git-lost+found
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.
Linus TorvaldsFix git-rev-list "date order" with --topo-order
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; }