{"thread":{"id":"7762","subject":"[RFH] WTF did we change in git-fsck recently?","startedAt":"2007-04-21T00:30:31Z","lastAt":"2007-04-21T20:36:06Z","messageCount":5,"participants":["Junio C Hamano","Linus Torvalds"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"40017","messageId":"7vps5ywouw.fsf@assigned-by-dhcp.cox.net","threadId":"7762","inReplyTo":null,"subject":"[RFH] WTF did we change in git-fsck recently?","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2007-04-21T00:30:31Z","receivedAt":"2007-04-21T00:30:31Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"I noticed that \"git-fsck --full\" from 'master' takes forever to\nfsck the kernel repository (I left it running for 2 hours before\nkilling it), while the one from 'maint' (or 1.5.1.1 which is\ninstalled on kernel.org) finishes within 2 or 3 minutes.  There\nis some serious breakages there.\n\nRings a bell?\n"},{"id":"40021","messageId":"alpine.LFD.0.98.0704201823310.9964@woody.linux-foundation.org","threadId":"7762","inReplyTo":"7vps5ywouw.fsf@assigned-by-dhcp.cox.net","subject":"Re: [RFH] WTF did we change in git-fsck recently?","fromName":"Linus Torvalds","fromEmail":"torvalds@linux-foundation.org","sentAt":"2007-04-21T01:24:13Z","receivedAt":"2007-04-21T01:24:13Z","isPatch":false,"sender":{"key":"torvalds@linux-foundation.org","avatar":"https://avatars.githubusercontent.com/u/1024025?v=4"},"body":"\n\nOn Fri, 20 Apr 2007, Junio C Hamano wrote:\n>\n> I noticed that \"git-fsck --full\" from 'master' takes forever to\n> fsck the kernel repository (I left it running for 2 hours before\n> killing it), while the one from 'maint' (or 1.5.1.1 which is\n> installed on kernel.org) finishes within 2 or 3 minutes.  There\n> is some serious breakages there.\n\nHmm. Probably something broken in my \"object decorator\" thing then. \n\nWill check it out, I hadn't noticed myself.\n\n\t\tLinus\n"},{"id":"40022","messageId":"alpine.LFD.0.98.0704201826350.9964@woody.linux-foundation.org","threadId":"7762","inReplyTo":"alpine.LFD.0.98.0704201823310.9964@woody.linux-foundation.org","subject":"Re: [RFH] WTF did we change in git-fsck recently?","fromName":"Linus Torvalds","fromEmail":"torvalds@linux-foundation.org","sentAt":"2007-04-21T01:30:06Z","receivedAt":"2007-04-21T01:30:06Z","isPatch":false,"sender":{"key":"torvalds@linux-foundation.org","avatar":"https://avatars.githubusercontent.com/u/1024025?v=4"},"body":"\n\nOn Fri, 20 Apr 2007, Linus Torvalds wrote:\n> \n> Hmm. Probably something broken in my \"object decorator\" thing then. \n\nDuh.\n\nWhen I did the object decorator thing, I made the \"loop over the hash\" \nfunction use the same logic for updating the hash, ie made them use\n\n\tif (++j >= size)\n\t\tj = 0;\n\nfor both the hash update for both \"insert\" and \"lookup\"\n\nHOWEVER.\n\nFor some inexplicable reason I had an extraneous\n\n\tj++;\n\nin the insert path (probably just from the fact that the old code there \nused \n\n\tj++;\n\tif (j >= size)\n\t\tj = 0;\n\nand when I made them use the same logic I just didn't remove the old \nextraneous line properly.\n\nThis fixes it.\n\nSigned-off-by: Linus Torvalds <torvalds@linux-foundation.org>\n---\n decorate.c |    1 -\n 1 files changed, 0 insertions(+), 1 deletions(-)\n\ndiff --git a/decorate.c b/decorate.c\nindex 396b413..23f6b00 100644\n--- a/decorate.c\n+++ b/decorate.c\n@@ -24,7 +24,6 @@ static void *insert_decoration(struct decoration *n, struct object *base, void *\n \t\t\thash[j].decoration = decoration;\n \t\t\treturn old;\n \t\t}\n-\t\tj++;\n \t\tif (++j >= size)\n \t\t\tj = 0;\n \t}\n"},{"id":"40025","messageId":"7v7is6wjx6.fsf@assigned-by-dhcp.cox.net","threadId":"7762","inReplyTo":"alpine.LFD.0.98.0704201826350.9964@woody.linux-foundation.org","subject":"Re: [RFH] WTF did we change in git-fsck recently?","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2007-04-21T02:17:09Z","receivedAt":"2007-04-21T02:17:09Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Linus Torvalds <torvalds@linux-foundation.org> writes:\n\n> On Fri, 20 Apr 2007, Linus Torvalds wrote:\n>> \n>> Hmm. Probably something broken in my \"object decorator\" thing then. \n>\n> Duh.\n\nThanks.\n"},{"id":"40072","messageId":"7vps5xsbwp.fsf_-_@assigned-by-dhcp.cox.net","threadId":"7762","inReplyTo":"7v7is6wjx6.fsf@assigned-by-dhcp.cox.net","subject":"Automated bisect success story","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2007-04-21T20:36:06Z","receivedAt":"2007-04-21T20:36:06Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Learning from example by Steven Grimm, let me share a success\nstory.\n\nEarlier I noticed that \"fsck --full\" from 'master' took forever\nin linux-2.6 repository, but the one from 'maint' finished in 2\nto 3 minutes.\n\nWe recently had a few enhancements by Christian Couder to\ngit-bisect, and this was a perfect opportunity to see how well\nthey worked:\n\n(1) \"git bisect start\" now takes one bad and then one or more\n    good commits, before suggesting the first revision to try.\n\nTraditionally, immediately after you gave a bad and a good\ncommit, it did a single bisection and then a checkout.  This\navoids repeated bisect computation and checkout when you know\nmore than one good revisions before starting to bisect, and also\nlet you bootstrap with a single command (you could instead give\none good commit at a time and then finally a single bad commit\nto avoid the waste).\n\nNot only I know 'maint' is good, I also know that the tips of\n\"foreign projects\" merged to git.git, that do not share any\ncodepath the fsck takes, are irrelevant to the problem.  So I\nwant to mark tips of commit ancestry I merged from git-gui\nprojects as good.  Hence:\n\n\t$ git bisect start master maint remotes/git-gui/master\n\nMnemonic.  Start takes a Bad before Goods, because B comes\nbefore G.\n\n(2) \"git bisect run <script>\" takes a script to judge the\n    goodness of the given revision.  Because I know each round\n    of test takes around 3 minutes, I wrote a little script to\n    automate the process and gave it to \"git bisect run\":\n\n\t$ git bisect run ./+run-script\n\nThis ran for a while (I do not know how long it took -- I was\naway from the machine and doing other things) and came back with\nthe \"object decoration\" one Linus has fixed yesterday with his\npatch.\n\nHere is the \"+run-script\".  I have git.git repository and\nlinux-2.6 repository next to each other.\n\n-- >8 --\n#!/bin/sh\n\n# Build errors are not what I am interested in.\nmake git-fsck && cd ../linux-2.6 || exit 255\n\n# We are checking if it stops in a reasonable amount of time, so\n# let it run in the background...\n\n../git.git/git-fsck --full >:log 2>&1 &\n\n# ... and grab its process ID.\nfsck=$!\n\n# ... and then wait for sufficiently long.\nsleep 240\n\n# ... and then see if the process is still there.\nif kill -0 $fsck\nthen\n\t# It is still running -- that is bad.\n        # Three-kill is just a ritual and has no real meaning.\n        # It is like \"sync;sync;sync;reboot\".\n\tkill $fsck; sleep 1; kill $fsck; sleep 1; kill $fsck;\n\texit 1\nelse\n\t# It has already finished (the $fsck process was no more),\n        # and we are happy.\n\texit 0\nfi\n"}]}