{"thread":{"id":"2404","subject":"Regarding: git-lost+found","startedAt":"2005-11-08T17:13:06Z","lastAt":"2005-11-14T18:01:26Z","messageCount":9,"participants":["Johannes Schindelin","Petr Baudis","Junio C Hamano","Daniel Barkalow","Matthias Urlichs","Linus Torvalds"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"11332","messageId":"Pine.LNX.4.63.0511081811080.18406@wbgn013.biozentrum.uni-wuerzburg.de","threadId":"2404","inReplyTo":null,"subject":"Regarding: git-lost+found","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2005-11-08T17:13:06Z","receivedAt":"2005-11-08T17:13:06Z","isPatch":false,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi,\n\nI think this is a valuable addition to the \"Now what?\" part of git. \nHowever, I'd like to see the results stored into .git/refs/lost+found/ \nrather than .git/lost+found/, so that it is possible to inspect them \neasily with gitk or git-show-branch.\n\nJust my sue tents,\nDscho\n"},{"id":"11335","messageId":"20051108174524.GD1431@pasky.or.cz","threadId":"2404","inReplyTo":"Pine.LNX.4.63.0511081811080.18406@wbgn013.biozentrum.uni-wuerzburg.de","subject":"Re: Regarding: git-lost+found","fromName":"Petr Baudis","fromEmail":"pasky@suse.cz","sentAt":"2005-11-08T17:45:24Z","receivedAt":"2005-11-08T17:45:24Z","isPatch":false,"sender":{"key":"pasky@ucw.cz","avatar":"https://avatars.githubusercontent.com/u/18439?v=4"},"body":"Dear diary, on Tue, Nov 08, 2005 at 06:13:06PM CET, I got a letter\nwhere Johannes Schindelin told me that...\n> I think this is a valuable addition to the \"Now what?\" part of git. \n> However, I'd like to see the results stored into .git/refs/lost+found/ \n> rather than .git/lost+found/, so that it is possible to inspect them \n> easily with gitk or git-show-branch.\n\nWhat is it supposed to be?\n\n-- \n\t\t\t\tPetr \"Pasky\" Baudis\nStuff: http://pasky.or.cz/\nVI has two modes: the one in which it beeps and the one in which\nit doesn't.\n"},{"id":"11336","messageId":"20051108174846.GE1431@pasky.or.cz","threadId":"2404","inReplyTo":"20051108174524.GD1431@pasky.or.cz","subject":"Re: Regarding: git-lost+found","fromName":"Petr Baudis","fromEmail":"pasky@suse.cz","sentAt":"2005-11-08T17:48:46Z","receivedAt":"2005-11-08T17:48:46Z","isPatch":false,"sender":{"key":"pasky@ucw.cz","avatar":"https://avatars.githubusercontent.com/u/18439?v=4"},"body":"> > I think this is a valuable addition to the \"Now what?\" part of git. \n> > However, I'd like to see the results stored into .git/refs/lost+found/ \n> > rather than .git/lost+found/, so that it is possible to inspect them \n> > easily with gitk or git-show-branch.\n> \n> What is it supposed to be?\n\nSorry for the noise - /lost.found/ found some matches (see the \"what\nafter 0.98\" mail from Junio). (Still, it would be helpful to put a\nreference to your mail.)\n\n-- \n\t\t\t\tPetr \"Pasky\" Baudis\nStuff: http://pasky.or.cz/\nVI has two modes: the one in which it beeps and the one in which\nit doesn't.\n"},{"id":"11405","messageId":"7vvez1bjjv.fsf@assigned-by-dhcp.cox.net","threadId":"2404","inReplyTo":"Pine.LNX.4.63.0511081811080.18406@wbgn013.biozentrum.uni-wuerzburg.de","subject":"Re: Regarding: git-lost+found","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2005-11-09T21:25:24Z","receivedAt":"2005-11-09T21:25:24Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Johannes Schindelin writes:\n\n> I think this is a valuable addition to the \"Now what?\" part of git. \n> However, I'd like to see the results stored into .git/refs/lost+found/ \n> rather than .git/lost+found/, so that it is possible to inspect them \n> easily with gitk or git-show-branch.\n\nI've thought about it, but on the other hand, having them under\nrefs/ hierarchy means fsck-objects would think they are relevant\nand prune would never be able to remove them anymore.\n\nThe scenario that git-lost+found would be useful is after you\ndid 'git branch -D', 'git tag -d', or 'git tag -f' and removed\nsomething you did not mean to by accident. You would find what\nyou want with git-lost+found and perhaps with help from gitk,\nand then reconnect them. At that point, it is very likely that\nyou would forget to clean the remainder afterwards. Later, you\nprobably forget you have ever run git-lost+found, and would\nstart wondering why git-prune would not remove any leftover\nanymore.\n\nMaybe we could use .git/lost+found/{commit,other}/?{40} and hang\ncommittish under one directory and the rest in another? Then we\ncould do this:\n\n $ gitk $(cd .git/lost+found/commit && echo ??*)\n\nAfter you find what you want, you would do 'git tag' or 'git\nbranch' to reconnect them, but we can reasonably expect that is\nto happen soon after you ran lost+found and before the next time\nyou run prune, because that was why you ran git-lost+found in\nthe first place.\n\nPrune will remove the objects reachable only from lost+found, so\nthe above gitk command line would fail if run after you did\ngit-lost+found and then git-prune in this order, but that is an\nunlikely sequence.\n\nSo, based on the above reasoning, how about this one?\n\n-- >8 -- cut here -- >8 --\n[PATCH] lost+found: make it a bit more useful with gitk\n\nThis separates the committish from others when resurrecting\ndangling objects to .git/lost+found/ hierarchy. After running\ngit-lost+found command, you could:\n\n $ gitk $(cd .git/lost+found/commit && echo ??*)\n\nto see how these branches came about from known old tags.\n\n---\ndiff --git a/git-lost+found.sh b/git-lost+found.sh\nindex bc1e988..b6b2616 100755\n--- a/git-lost+found.sh\n+++ b/git-lost+found.sh\n@@ -3,18 +3,21 @@\n . git-sh-setup || die \"Not a git archive.\"\n \n laf=\"$GIT_DIR/lost+found\"\n-mkdir -p \"$laf\" || exit\n+rm -fr \"$laf\" && mkdir -p \"$laf/commit\" \"$laf/other\" || exit\n \n git fsck-objects |\n while read dangling type sha1\n do\n \tcase \"$dangling\" in\n \tdangling)\n-\t\techo \"$sha1\" >\"$laf/$sha1\"\n-\t\tcase \"$type\" in\n-\t\tcommit | tag)\n-\t\t\tgit-show-branch \"$sha1\" ;;\n-\t\tesac\n+\t\tif git-rev-parse --verify \"$sha1^0\" >/dev/null 2>/dev/null\n+\t\tthen\n+\t\t\tdir=\"$laf/commit\"\n+\t\t\tgit-show-branch \"$sha1\"\n+\t\telse\n+\t\t\tdir=\"$laf/other\"\n+\t\tfi\n+\t\techo \"$sha1\" >\"$dir/$sha1\"\n \t\t;;\n \tesac\n done\n"},{"id":"11422","messageId":"Pine.LNX.4.64.0511091759520.25300@iabervon.org","threadId":"2404","inReplyTo":"7vvez1bjjv.fsf@assigned-by-dhcp.cox.net","subject":"Re: Regarding: git-lost+found","fromName":"Daniel Barkalow","fromEmail":"barkalow@iabervon.org","sentAt":"2005-11-09T23:06:04Z","receivedAt":"2005-11-09T23:06:04Z","isPatch":false,"sender":{"key":"barkalow@iabervon.org","avatar":"https://avatars.githubusercontent.com/u/55364219?v=4"},"body":"On Wed, 9 Nov 2005, Junio C Hamano wrote:\n\n> Maybe we could use .git/lost+found/{commit,other}/?{40} and hang\n> committish under one directory and the rest in another? Then we\n> could do this:\n> \n> $ gitk $(cd .git/lost+found/commit && echo ??*)\n> \n> After you find what you want, you would do 'git tag' or 'git\n> branch' to reconnect them, but we can reasonably expect that is\n> to happen soon after you ran lost+found and before the next time\n> you run prune, because that was why you ran git-lost+found in\n> the first place.\n\nWhy have git-lost+found write to files at all? It seems to me easiest to \nhave the list go to standard out, and you could do \"gitk `git-lost+found \n-t commit`\" to see lost commits, and reconnect them as desired. (Making up \ncommand line syntax for listing only the commits.)\n\n\t-Daniel\n*This .sig left intentionally blank*\n"},{"id":"11429","messageId":"7vwtjh8kxu.fsf@assigned-by-dhcp.cox.net","threadId":"2404","inReplyTo":"Pine.LNX.4.64.0511091759520.25300@iabervon.org","subject":"Re: Regarding: git-lost+found","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2005-11-09T23:23:41Z","receivedAt":"2005-11-09T23:23:41Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Daniel Barkalow writes:\n\n> Why have git-lost+found write to files at all? It seems to me easiest to \n> have the list go to standard out, and you could do \"gitk `git-lost+found \n> -t commit`\" to see lost commits, and reconnect them as desired. (Making up \n> command line syntax for listing only the commits.)\n\nThat is certainly cleaner. The only downside is fsck-objects\nthat lost+found uses tends to be expensive operation, and what\nyou would want to do with the information may be more than just\nuse it on the command line of gitk. But in any case the user\ncould store git-lost+found output in a file to do whatever she\nwants, so it may not matter.\n"},{"id":"11446","messageId":"Pine.LNX.4.64.0511091926350.25300@iabervon.org","threadId":"2404","inReplyTo":"7vwtjh8kxu.fsf@assigned-by-dhcp.cox.net","subject":"Re: Regarding: git-lost+found","fromName":"Daniel Barkalow","fromEmail":"barkalow@iabervon.org","sentAt":"2005-11-10T00:29:54Z","receivedAt":"2005-11-10T00:29:54Z","isPatch":false,"sender":{"key":"barkalow@iabervon.org","avatar":"https://avatars.githubusercontent.com/u/55364219?v=4"},"body":"On Wed, 9 Nov 2005, Junio C Hamano wrote:\n\n> Daniel Barkalow writes:\n> \n> > Why have git-lost+found write to files at all? It seems to me easiest to \n> > have the list go to standard out, and you could do \"gitk `git-lost+found \n> > -t commit`\" to see lost commits, and reconnect them as desired. (Making up \n> > command line syntax for listing only the commits.)\n> \n> That is certainly cleaner. The only downside is fsck-objects\n> that lost+found uses tends to be expensive operation, and what\n> you would want to do with the information may be more than just\n> use it on the command line of gitk. But in any case the user\n> could store git-lost+found output in a file to do whatever she\n> wants, so it may not matter.\n\nActually, my next suggestion would be to have gitk able to write \nhashes as refs, so that, having put it on the gitk command line, you could \nthen do the things you want from there.\n\n\t-Daniel\n*This .sig left intentionally blank*\n"},{"id":"11756","messageId":"pan.2005.11.14.04.36.38.784541@smurf.noris.de","threadId":"2404","inReplyTo":"7vvez1bjjv.fsf@assigned-by-dhcp.cox.net","subject":"Re: Regarding: git-lost+found","fromName":"Matthias Urlichs","fromEmail":"smurf@smurf.noris.de","sentAt":"2005-11-14T04:36:40Z","receivedAt":"2005-11-14T04:36:40Z","isPatch":false,"sender":{"key":"matthias@urlichs.de","avatar":"https://gravatar.com/avatar/2708905af227313eba6f2b2ae0f7d0259b5ac5d71baef58fe5a13c699ce0bbf0?d=mp&s=160"},"body":"Hi, Junio C Hamano wrote:\n\n> $ gitk $(cd .git/lost+found/commit && echo ??*)\n\nAlong those lines... I just tried that, it found a whole heap of old\ncommits I didn't yet clean up, and they're sorted by their SHA1.\n\nIn other words, actually finding the latest commit in there was a\nnontrivial task.\n\nI don't speak tcl, so could somebody please change \"gitk -d\" to sort its\ncommand line by date (newest first, of course)? Thanks.\n\n-- \nMatthias Urlichs | {M:U} IT Design @ m-u-it.de | smurf@smurf.noris.de\nDisclaimer: The quote was selected randomly. Really. | http://smurf.noris.de\n - -\nInnocence ends when one is stripped of the delusion that one likes\noneself.\n"},{"id":"11820","messageId":"Pine.LNX.4.64.0511140940100.3263@g5.osdl.org","threadId":"2404","inReplyTo":"pan.2005.11.14.04.36.38.784541@smurf.noris.de","subject":"Fix git-rev-list \"date order\" with --topo-order","fromName":"Linus Torvalds","fromEmail":"torvalds@osdl.org","sentAt":"2005-11-14T18:01:26Z","receivedAt":"2005-11-14T18:01:26Z","isPatch":false,"sender":{"key":"torvalds@linux-foundation.org","avatar":"https://avatars.githubusercontent.com/u/1024025?v=4"},"body":"\nThis fixes git-rev-list so that when there are multiple branches, we still \nsort the heads in proper approximate date order even when sorting the \noutput topologically.\n\nThis makes things like\n\n\tgitk --all -d\n\nwork sanely and show the branches in date order (where \"date order\" is \nobviously modified by the paren-child dependency requirements of the \ntopological sort).\n\nThe trivial fix is to just build the \"work\" list in date order rather than \ninserting the new work entries at the beginning.\n\nSigned-off-by: Linus Torvalds \n---\n\nThis should also fix this report, although Matthias should double-test..\n\nOn Mon, 14 Nov 2005, Matthias Urlichs wrote:\n> \n> > $ gitk $(cd .git/lost+found/commit && echo ??*)\n> \n> Along those lines... I just tried that, it found a whole heap of old\n> commits I didn't yet clean up, and they're sorted by their SHA1.\n> \n> In other words, actually finding the latest commit in there was a\n> nontrivial task.\n> \n> I don't speak tcl, so could somebody please change \"gitk -d\" to sort its\n> command line by date (newest first, of course)? Thanks.\n\ndiff --git a/commit.c b/commit.c\nindex 534c03e..ebf4db6 100644\n--- a/commit.c\n+++ b/commit.c\n@@ -536,7 +536,7 @@ int count_parents(struct commit * commit\n void sort_in_topological_order(struct commit_list ** list)\n {\n \tstruct commit_list * next = *list;\n-\tstruct commit_list * work = NULL;\n+\tstruct commit_list * work = NULL, **insert;\n \tstruct commit_list ** pptr = list;\n \tstruct sort_node * nodes;\n \tstruct sort_node * next_nodes;\n@@ -580,11 +580,12 @@ void sort_in_topological_order(struct co\n * the tips serve as a starting set for the work queue.\n */\n \tnext=*list;\n+\tinsert = &work;\n \twhile (next) {\n \t\tstruct sort_node * node = (struct sort_node *)next->item->object.util;\n \n \t\tif (node->indegree == 0) {\n-\t\t\tcommit_list_insert(next->item, &work);\n+\t\t\tinsert = &commit_list_insert(next->item, insert)->next;\n \t\t}\n \t\tnext=next->next;\n \t}\n"}]}