{"thread":{"id":"9153","subject":"[PATCH] fsck --lost-found: write blob's contents, not their SHA-1","startedAt":"2007-07-22T20:20:26Z","lastAt":"2007-07-22T23:00:49Z","messageCount":4,"participants":["Johannes Schindelin","Junio C Hamano"],"isPatch":true,"patchVersion":1,"patchTotal":null},"messages":[{"id":"48183","messageId":"Pine.LNX.4.64.0707222120100.14781@racer.site","threadId":"9153","inReplyTo":null,"subject":"[PATCH] fsck --lost-found: write blob's contents, not their SHA-1","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2007-07-22T20:20:26Z","receivedAt":"2007-07-22T20:20:26Z","isPatch":true,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"\nWhen looking for a lost blob, it is much nicer to be able to grep\nthrough .git/lost-found/other/* than to write an inefficient loop\nover the file names.  So write the contents of the dangling blobs,\nnot their object names.\n\nSigned-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>\n---\n\n\tWhile working on filter-branch, I inadvertently said\n\t\"git reset --hard\" without having committed first.  That's\n\twhen I was almost happy to have \"git fsck --lost-found\".\n\tBut when grepping through the \"other\" found objects, nothing\n\tturned up... because there were only SHA-1s.\n\n Documentation/git-fsck.txt |    6 ++++--\n builtin-fsck.c             |   12 +++++++++++-\n 2 files changed, 15 insertions(+), 3 deletions(-)\n\ndiff --git a/Documentation/git-fsck.txt b/Documentation/git-fsck.txt\nindex 1a432f2..45c0bee 100644\n--- a/Documentation/git-fsck.txt\n+++ b/Documentation/git-fsck.txt\n@@ -65,8 +65,10 @@ index file and all SHA1 references in .git/refs/* as heads.\n \tBe chatty.\n \n --lost-found::\n-\tWrite dangling refs into .git/lost-found/commit/ or\n-\t.git/lost-found/other/, depending on type.\n+\tWrite dangling objects into .git/lost-found/commit/ or\n+\t.git/lost-found/other/, depending on type.  If the object is\n+\ta blob, the contents are written into the file, rather than\n+\tits object name.\n \n It tests SHA1 and general object sanity, and it does full tracking of\n the resulting reachability and everything else. It prints out any\ndiff --git a/builtin-fsck.c b/builtin-fsck.c\nindex 350ec5e..8d12287 100644\n--- a/builtin-fsck.c\n+++ b/builtin-fsck.c\n@@ -152,7 +152,17 @@ static void check_unreachable_object(struct object *obj)\n \t\t\t}\n \t\t\tif (!(f = fopen(filename, \"w\")))\n \t\t\t\tdie(\"Could not open %s\", filename);\n-\t\t\tfprintf(f, \"%s\\n\", sha1_to_hex(obj->sha1));\n+\t\t\tif (obj->type == OBJ_BLOB) {\n+\t\t\t\tenum object_type type;\n+\t\t\t\tunsigned long size;\n+\t\t\t\tchar *buf = read_sha1_file(obj->sha1,\n+\t\t\t\t\t\t&type, &size);\n+\t\t\t\tif (buf) {\n+\t\t\t\t\tfwrite(buf, size, 1, f);\n+\t\t\t\t\tfree(buf);\n+\t\t\t\t}\n+\t\t\t} else\n+\t\t\t\tfprintf(f, \"%s\\n\", sha1_to_hex(obj->sha1));\n \t\t\tfclose(f);\n \t\t}\n \t\treturn;\n-- \n1.5.3.rc2.32.g35c5b\n"},{"id":"48198","messageId":"7vodi4qfnx.fsf@assigned-by-dhcp.cox.net","threadId":"9153","inReplyTo":"Pine.LNX.4.64.0707222120100.14781@racer.site","subject":"Re: [PATCH] fsck --lost-found: write blob's contents, not their SHA-1","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2007-07-22T21:42:10Z","receivedAt":"2007-07-22T21:42:10Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:\n\n> When looking for a lost blob, it is much nicer to be able to grep\n> through .git/lost-found/other/* than to write an inefficient loop\n> over the file names.  So write the contents of the dangling blobs,\n> not their object names.\n\nI think this is an idea to solve a good problem, but if we go\nthis route, the need for us to worry about expiring lost-found\nentries would become more urgent, I suspect.\n\nAnd when you think about expiring lost-found entries, another\npossible solution emerges.  If we teach git-prune to remove the\ncorresponding entry from lost-found/other when it removes a\nloose blob from the object store, then we can easily and safely\ndo this instead:\n\n\t$ cat .git/lost-found/other/* |\n\t  xargs -r git grep 'the word to look for'\n"},{"id":"48203","messageId":"Pine.LNX.4.64.0707222246220.14781@racer.site","threadId":"9153","inReplyTo":"7vodi4qfnx.fsf@assigned-by-dhcp.cox.net","subject":"Re: [PATCH] fsck --lost-found: write blob's contents, not their SHA-1","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2007-07-22T21:52:28Z","receivedAt":"2007-07-22T21:52:28Z","isPatch":true,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi,\n\nOn Sun, 22 Jul 2007, Junio C Hamano wrote:\n\n> Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:\n> \n> > When looking for a lost blob, it is much nicer to be able to grep\n> > through .git/lost-found/other/* than to write an inefficient loop\n> > over the file names.  So write the contents of the dangling blobs,\n> > not their object names.\n> \n> I think this is an idea to solve a good problem, but if we go\n> this route, the need for us to worry about expiring lost-found\n> entries would become more urgent, I suspect.\n\nWhy?  AFAICT lost+found/ has to be cleaned by people.  So if you look for \nsomething, you say \"git fsck --lost-found\", and once you found it, it's \ntime for \"rm -rf .git/lost-found\".\n\n> And when you think about expiring lost-found entries, another\n> possible solution emerges.  If we teach git-prune to remove the\n> corresponding entry from lost-found/other when it removes a\n> loose blob from the object store, then we can easily and safely\n> do this instead:\n> \n> \t$ cat .git/lost-found/other/* |\n> \t  xargs -r git grep 'the word to look for'\n\nWell, it is not only for grepping.  In my case, I could get away by this:\n\n$ ls -lrt $(grep -l filter_subdir .git/lost-found/other/* |\n\tsed \"s/^.*other\\/\\(..\\)/.git\\/objects\\/\\1\\//\") \n\nIOW I found the loose dangling objects which matched a keyword, and sorted \nthem by time.\n\nIn other cases, though, I wanted to see the size.\n\nBut what the whole thing boils down to: After finding dangling objects, \nyou are much more likely using git tools on non-blobs than on blobs, and \nvice versa.\n\nCiao,\nDscho\n\nP.S.: I fully forgot to mention that happily, I did \"git add -u\" sometime \nbefore \"git reset --hard\", otherwise I would have been lost.\n"},{"id":"48235","messageId":"7v4pjwqc0u.fsf@assigned-by-dhcp.cox.net","threadId":"9153","inReplyTo":"Pine.LNX.4.64.0707222246220.14781@racer.site","subject":"Re: [PATCH] fsck --lost-found: write blob's contents, not their SHA-1","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2007-07-22T23:00:49Z","receivedAt":"2007-07-22T23:00:49Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:\n\n> But what the whole thing boils down to: After finding dangling objects, \n> you are much more likely using git tools on non-blobs than on blobs, and \n> vice versa.\n\nOk, color me converted.\n"}]}