{"thread":{"id":"17430","subject":"Something weird is happening...","startedAt":"2009-01-29T06:24:36Z","lastAt":"2009-02-01T01:31:42Z","messageCount":25,"participants":["H. Peter Anvin","Junio C Hamano","Ingo Molnar","Sverre Rabbelier","René Scharfe","Daniel Barkalow","Linus Torvalds","Johannes Sixt","Johannes Schindelin","Nanako Shiraishi"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"102409","messageId":"49814BA4.6030705@zytor.com","threadId":"17430","inReplyTo":null,"subject":"Something weird is happening...","fromName":"H. Peter Anvin","fromEmail":"hpa@zytor.com","sentAt":"2009-01-29T06:24:36Z","receivedAt":"2009-01-29T06:24:36Z","isPatch":false,"sender":{"key":"hpa@zytor.com","avatar":null},"body":"I was investigating a problem that Ingo Molnar reported on the\nlinux-2.6-tip.git repository on kernel.org.  Unfortunately I was not\nable to reproduce his problem (which is a problem in itself) but I did\nrun into another oddity:\n\n: hera 4 ; git fsck\n\n[lots of dangling commits deleted]\nmissing blob af0e01d4c663a101f48614e40d006ed6272d5c36\n\n: hera 5 ; git cat-file blob af0e01d4c663a101f48614e40d006ed6272d5c36\n/*\n *  debugfs.h - a tiny little debug file system\n *\n *  Copyright (C) 2004 Greg Kroah-Hartman <greg@kroah.com>\n *  Copyright (C) 2004 IBM Inc.\n *\n[... rest of blob deleted ...]\n\nOkay, what is going on here?\n\nSince git 1.6.1.1 just got installed on kernel.org, this phenomenon (and\nhopefully Ingo's problem, too) maybe has something to do with this new\nversion?\n\n\t-hpa\n\n--\nH. Peter Anvin, Intel Open Source Technology Center\nI work for Intel.  I don't speak on their behalf.\n"},{"id":"102410","messageId":"7vr62mha7a.fsf@gitster.siamese.dyndns.org","threadId":"17430","inReplyTo":"49814BA4.6030705@zytor.com","subject":"Re: Something weird is happening...","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2009-01-29T06:56:25Z","receivedAt":"2009-01-29T06:56:25Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"\"H. Peter Anvin\" <hpa@zytor.com> writes:\n\n> I was investigating a problem that Ingo Molnar reported on the\n> linux-2.6-tip.git repository on kernel.org.  Unfortunately I was not\n> able to reproduce his problem (which is a problem in itself) but I did\n> run into another oddity:\n>\n> : hera 4 ; git fsck\n>\n> [lots of dangling commits deleted]\n> missing blob af0e01d4c663a101f48614e40d006ed6272d5c36\n>\n> : hera 5 ; git cat-file blob af0e01d4c663a101f48614e40d006ed6272d5c36\n> /*\n>  *  debugfs.h - a tiny little debug file system\n>  *\n>  *  Copyright (C) 2004 Greg Kroah-Hartman <greg@kroah.com>\n>  *  Copyright (C) 2004 IBM Inc.\n>  *\n> [... rest of blob deleted ...]\n>\n> Okay, what is going on here?\n\nDoes \"git fsck --full\" report the blob missing?\n"},{"id":"102428","messageId":"20090129105003.GB10987@elte.hu","threadId":"17430","inReplyTo":"49814BA4.6030705@zytor.com","subject":"Re: Something weird is happening...","fromName":"Ingo Molnar","fromEmail":"mingo@elte.hu","sentAt":"2009-01-29T10:50:03Z","receivedAt":"2009-01-29T10:50:03Z","isPatch":false,"sender":{"key":"mingo@elte.hu","avatar":null},"body":"\n* H. Peter Anvin <hpa@zytor.com> wrote:\n\n> I was investigating a problem that Ingo Molnar reported on the \n> linux-2.6-tip.git repository on kernel.org.  Unfortunately I was not \n> able to reproduce his problem (which is a problem in itself) but I did \n> run into another oddity:\n> \n> : hera 4 ; git fsck\n> \n> [lots of dangling commits deleted]\n> missing blob af0e01d4c663a101f48614e40d006ed6272d5c36\n\nThis problem went away as i downgraded my version of Git from the 'maint' \nbranch to a distro 1.6.0 version.\n\n\tIngo\n"},{"id":"102429","messageId":"20090129105223.GA21080@elte.hu","threadId":"17430","inReplyTo":"20090129105003.GB10987@elte.hu","subject":"Re: Something weird is happening...","fromName":"Ingo Molnar","fromEmail":"mingo@elte.hu","sentAt":"2009-01-29T10:52:23Z","receivedAt":"2009-01-29T10:52:23Z","isPatch":false,"sender":{"key":"mingo@elte.hu","avatar":null},"body":"\n* Ingo Molnar <mingo@elte.hu> wrote:\n\n> \n> * H. Peter Anvin <hpa@zytor.com> wrote:\n> \n> > I was investigating a problem that Ingo Molnar reported on the \n> > linux-2.6-tip.git repository on kernel.org.  Unfortunately I was not \n> > able to reproduce his problem (which is a problem in itself) but I did \n> > run into another oddity:\n> > \n> > : hera 4 ; git fsck\n> > \n> > [lots of dangling commits deleted]\n> > missing blob af0e01d4c663a101f48614e40d006ed6272d5c36\n> \n> This problem went away as i downgraded my version of Git from the \n> 'maint' branch to a distro 1.6.0 version.\n\nthe last 'bad' version of git that i tried was:\n\n    v1.6.1.1-259-g8712b3c\n\nthe 'good' version is:\n\n    git version 1.6.0.6\n\nbut i had a previous version as well, about 2 weeks older than \nv1.6.1.1-259-g8712b3c - and it only started triggering these problems once \nthe kernel.org upgrade happened. I have no clean reproducer so you can \nignore this - my use of versions was a bit messy.\n\n\tIngo\n"},{"id":"102439","messageId":"20090129120539.GA26975@elte.hu","threadId":"17430","inReplyTo":"20090129113846.GA10645@elte.hu","subject":"Re: Something weird is happening...","fromName":"Ingo Molnar","fromEmail":"mingo@elte.hu","sentAt":"2009-01-29T12:05:39Z","receivedAt":"2009-01-29T12:05:39Z","isPatch":false,"sender":{"key":"mingo@elte.hu","avatar":null},"body":"\n* Ingo Molnar <mingo@elte.hu> wrote:\n\n> a simple 'git fsck' still reports a ton of dangling and missing objects. \n> (see it below)\n> \n> amongst them is the object above:\n> \n>   missing blob af0e01d4c663a101f48614e40d006ed6272d5c36\n> \n> but this does not seem to cause problems with git version 1.6.0.6 that \n> i'm using now.\n\nhm - maybe it's unrelated, but yesterday, a few hours before the incident \ni did a higher-order Octopus merge with 1.6.1, that segfaulted.\n\nI didnt think much of it - git often crashes with our crazy -tip tree when \ni get above the magic 20 branches limit. The crash left a .git/index.lock \nfile around which i removed - and then forgot about the incident. I wanted \nto report those crashes before but procrastinated it.\n\nI used git/maint snapshots because new versions of Git are much better at \ndoing Octopus merges.\n\nI've written a reproducer for git-1.6.1.1-1.fc11.i386. See the crash log \nbelow.\n\nTo reproduce, pick up the -tip tree as a remote:\n\n   http://people.redhat.com/mingo/tip.git/README\n\n(you can run the README file as a script)\n\nThen do this:\n\n   git checkout -b tmp.crash v2.6.29-rc3\n\n   git merge  tip/x86/asm        tip/x86/cleanups     tip/x86/cpudetect    \\\n              tip/x86/debug      tip/x86/doc          tip/x86/header-fixes \\\n              tip/x86/mm         tip/x86/paravirt     tip/x86/pat          \\\n              tip/x86/setup-v2   tip/x86/subarch      tip/x86/uaccess      \\\n              tip/x86/urgent     tip/core/percpu\n\nand you should see the segfault.\n\ninterestingly i did not reproduce with the sha1's hardcoded:\n\n  git checkout -b tmp.crash 18e352e4a73465349711a9324767e1b2453383e2\n\n git merge 2d4d57db692ea790e185656516e6ebe8791f1788 a448720ca3248e8a7a426336885549d6e923fd8e b38b0665905538e76e26f2a4c686179abb1f69f6 d5e397cb49b53381e4c99a064ca733c665646de8 e56d0cfe7790fd3218ae4f6aae1335547fea8763 dbca1df48e89d8aa59254fdc10ef16c16e73d94e fb746d0e1365b7472ccc4c3d5b0672b34a092d0b 6522869c34664dd5f05a0a327e93915b1281c90d d639bab8da86d330493487e8c0fea8ca31f53427 042cbaf88ab48e11afb725541e3c2cbf5b483680 5662a2f8e7313f78d6b17ab383f3e4f04971c335 3b4b75700a245d0d48fc52a4d2f67d3155812aba bf3647c44bc76c43c4b2ebb4c37a559e899ac70e 4369f1fb7cd4cf777312f43e1cb9aa5504fc4125\n\n\tIngo\n\n-------------------->\nearth4:~/tip> git merge x86/asm x86/cleanups x86/cpudetect x86/debug \nx86/doc x86/header-fixes x86/mm x86/paravirt x86/pat x86/setup-v2 \nx86/subarch x86/uaccess x86/urgent core/percpu\nTrying simple merge with 2d4d57db692ea790e185656516e6ebe8791f1788\nTrying simple merge with a448720ca3248e8a7a426336885549d6e923fd8e\nSimple merge did not work, trying automatic merge.\nAuto-merging arch/x86/include/asm/io.h\nAuto-merging arch/x86/include/asm/spinlock.h\nAuto-merging arch/x86/kernel/mpparse.c\nAuto-merging arch/x86/kernel/setup_percpu.c\nAuto-merging arch/x86/mm/init_32.c\nTrying simple merge with b38b0665905538e76e26f2a4c686179abb1f69f6\nSimple merge did not work, trying automatic merge.\nAuto-merging arch/x86/kernel/cpu/common.c\nAuto-merging arch/x86/kernel/cpu/intel.c\nAuto-merging arch/x86/mm/pat.c\nTrying simple merge with d5e397cb49b53381e4c99a064ca733c665646de8\nTrying simple merge with e56d0cfe7790fd3218ae4f6aae1335547fea8763\nTrying simple merge with dbca1df48e89d8aa59254fdc10ef16c16e73d94e\nTrying simple merge with fb746d0e1365b7472ccc4c3d5b0672b34a092d0b\nTrying simple merge with 6522869c34664dd5f05a0a327e93915b1281c90d\nSimple merge did not work, trying automatic merge.\nAuto-merging arch/x86/include/asm/paravirt.h\nTrying simple merge with d639bab8da86d330493487e8c0fea8ca31f53427\nSimple merge did not work, trying automatic merge.\nAuto-merging arch/x86/include/asm/io.h\nAuto-merging arch/x86/mm/ioremap.c\nTrying simple merge with 042cbaf88ab48e11afb725541e3c2cbf5b483680\nTrying simple merge with 5662a2f8e7313f78d6b17ab383f3e4f04971c335\nTrying simple merge with 3b4b75700a245d0d48fc52a4d2f67d3155812aba\nSimple merge did not work, trying automatic merge.\nAuto-merging arch/x86/kernel/signal.c\nTrying simple merge with bf3647c44bc76c43c4b2ebb4c37a559e899ac70e\nSimple merge did not work, trying automatic merge.\nAuto-merging arch/x86/kernel/cpu/intel.c\nTrying simple merge with 4369f1fb7cd4cf777312f43e1cb9aa5504fc4125\n/usr/libexec/git-core/git-merge-octopus: line 52: 26758 Segmentation fault      \ngit read-tree -u -m --aggressive $common $MRT $SHA1\nMerge with strategy octopus failed.\nearth4:~/tip> \n"},{"id":"102446","messageId":"bd6139dc0901290545s1a5ba310u549338e823762ae1@mail.gmail.com","threadId":"17430","inReplyTo":"7vr62mha7a.fsf@gitster.siamese.dyndns.org","subject":"Re: Something weird is happening...","fromName":"Sverre Rabbelier","fromEmail":"srabbelier@gmail.com","sentAt":"2009-01-29T13:45:16Z","receivedAt":"2009-01-29T13:45:16Z","isPatch":false,"sender":{"key":"srabbelier@gmail.com","avatar":"https://avatars.githubusercontent.com/u/3098?v=4"},"body":"On Thu, Jan 29, 2009 at 07:56, Junio C Hamano <gitster@pobox.com> wrote:\n>> Okay, what is going on here?\n\nIs this perhaps related to the problem the github guys were having,\nits sounds similar, problem not showing up until after upgrade,\nmissing objects, no?\n\n-- \nCheers,\n\nSverre Rabbelier\n"},{"id":"102504","messageId":"7vfxj1eqh6.fsf@gitster.siamese.dyndns.org","threadId":"17430","inReplyTo":"49814BA4.6030705@zytor.com","subject":"Re: Something weird is happening...","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2009-01-29T21:45:25Z","receivedAt":"2009-01-29T21:45:25Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"\"H. Peter Anvin\" <hpa@zytor.com> writes:\n\n> I was investigating a problem that Ingo Molnar reported on the\n> linux-2.6-tip.git repository on kernel.org.  Unfortunately I was not\n> able to reproduce his problem (which is a problem in itself) but I did\n> run into another oddity:\n>\n> : hera 4 ; git fsck\n>\n> [lots of dangling commits deleted]\n> missing blob af0e01d4c663a101f48614e40d006ed6272d5c36\n>\n> : hera 5 ; git cat-file blob af0e01d4c663a101f48614e40d006ed6272d5c36\n> /*\n>  *  debugfs.h - a tiny little debug file system\n>  *\n>  *  Copyright (C) 2004 Greg Kroah-Hartman <greg@kroah.com>\n>  *  Copyright (C) 2004 IBM Inc.\n>  *\n> [... rest of blob deleted ...]\n>\n> Okay, what is going on here?\n\nIs the blob borrowed from one of its alternate object store, and not in a\npack?  That would explain (note that I am not saying \"justify\" here, just\n\"explain\") the symptom.\n\n\"git fsck\" unlike \"git fsck --full\" does not validate objects in pack nor\nobjects you borrow from your neighbour via objects/info/alternates.\n\nBut it still does the connectivity check fully from your refs.  And if it\nfinds an object that ought to be reachable from your refs that it hasn't\nvalidated, it gives the \"missing\" warning above.  There is a check to\nexclude objects in packs when running \"git fsck\" without --full from this\nwarning but I do not see a corresponding exclusion of objects that were\nborrowed from your neighbour which we didn't check either.\n\nBut that is just a conjecture from a cursory looking at the current code.\nI do not remember (or did not know from the beginning) some details of it.\nAnd that is why I asked you if \"git fsck --full\" reports it missing in my\nearlier response to you.\n"},{"id":"102508","messageId":"49822944.8000103@zytor.com","threadId":"17430","inReplyTo":"7vfxj1eqh6.fsf@gitster.siamese.dyndns.org","subject":"Re: Something weird is happening...","fromName":"H. Peter Anvin","fromEmail":"hpa@zytor.com","sentAt":"2009-01-29T22:10:12Z","receivedAt":"2009-01-29T22:10:12Z","isPatch":false,"sender":{"key":"hpa@zytor.com","avatar":null},"body":"Junio C Hamano wrote:\n> \n> Is the blob borrowed from one of its alternate object store, and not in a\n> pack?  That would explain (note that I am not saying \"justify\" here, just\n> \"explain\") the symptom.\n> \n\nYes, it is.\n\n> But it still does the connectivity check fully from your refs.  And if it\n> finds an object that ought to be reachable from your refs that it hasn't\n> validated, it gives the \"missing\" warning above.  There is a check to\n> exclude objects in packs when running \"git fsck\" without --full from this\n> warning but I do not see a corresponding exclusion of objects that were\n> borrowed from your neighbour which we didn't check either.\n> \n> But that is just a conjecture from a cursory looking at the current code.\n> I do not remember (or did not know from the beginning) some details of it.\n> And that is why I asked you if \"git fsck --full\" reports it missing in my\n> earlier response to you.\n\nJust tried it, it doesn't.  So I guess things are OK.\n\n\t-hpa\n"},{"id":"102509","messageId":"49822B91.6070303@lsrfire.ath.cx","threadId":"17430","inReplyTo":"20090129120539.GA26975@elte.hu","subject":"Re: Something weird is happening...","fromName":"René Scharfe","fromEmail":"rene.scharfe@lsrfire.ath.cx","sentAt":"2009-01-29T22:20:01Z","receivedAt":"2009-01-29T22:20:01Z","isPatch":false,"sender":{"key":"l.s.r@web.de","avatar":"https://avatars.githubusercontent.com/u/26122331?v=4"},"body":"Ingo Molnar schrieb:\n> * Ingo Molnar <mingo@elte.hu> wrote:\n> \n>> a simple 'git fsck' still reports a ton of dangling and missing objects. \n>> (see it below)\n>>\n>> amongst them is the object above:\n>>\n>>   missing blob af0e01d4c663a101f48614e40d006ed6272d5c36\n>>\n>> but this does not seem to cause problems with git version 1.6.0.6 that \n>> i'm using now.\n> \n> hm - maybe it's unrelated, but yesterday, a few hours before the incident \n> i did a higher-order Octopus merge with 1.6.1, that segfaulted.\n> \n> I didnt think much of it - git often crashes with our crazy -tip tree when \n> i get above the magic 20 branches limit. The crash left a .git/index.lock \n> file around which i removed - and then forgot about the incident. I wanted \n> to report those crashes before but procrastinated it.\n> \n> I used git/maint snapshots because new versions of Git are much better at \n> doing Octopus merges.\n> \n> I've written a reproducer for git-1.6.1.1-1.fc11.i386. See the crash log \n> below.\n> \n> To reproduce, pick up the -tip tree as a remote:\n> \n>    http://people.redhat.com/mingo/tip.git/README\n> \n> (you can run the README file as a script)\n> \n> Then do this:\n> \n>    git checkout -b tmp.crash v2.6.29-rc3\n> \n>    git merge  tip/x86/asm        tip/x86/cleanups     tip/x86/cpudetect    \\\n>               tip/x86/debug      tip/x86/doc          tip/x86/header-fixes \\\n>               tip/x86/mm         tip/x86/paravirt     tip/x86/pat          \\\n>               tip/x86/setup-v2   tip/x86/subarch      tip/x86/uaccess      \\\n>               tip/x86/urgent     tip/core/percpu\n> \n> and you should see the segfault.\n> \n> interestingly i did not reproduce with the sha1's hardcoded:\n> \n>   git checkout -b tmp.crash 18e352e4a73465349711a9324767e1b2453383e2\n> \n>  git merge 2d4d57db692ea790e185656516e6ebe8791f1788 a448720ca3248e8a7a426336885549d6e923fd8e b38b0665905538e76e26f2a4c686179abb1f69f6 d5e397cb49b53381e4c99a064ca733c665646de8 e56d0cfe7790fd3218ae4f6aae1335547fea8763 dbca1df48e89d8aa59254fdc10ef16c16e73d94e fb746d0e1365b7472ccc4c3d5b0672b34a092d0b 6522869c34664dd5f05a0a327e93915b1281c90d d639bab8da86d330493487e8c0fea8ca31f53427 042cbaf88ab48e11afb725541e3c2cbf5b483680 5662a2f8e7313f78d6b17ab383f3e4f04971c335 3b4b75700a245d0d48fc52a4d2f67d3155812aba bf3647c44bc76c43c4b2ebb4c37a559e899ac70e 4369f1fb7cd4cf777312f43e1cb9aa5504fc4125\n> \n> \tIngo\n> \n> -------------------->\n> earth4:~/tip> git merge x86/asm x86/cleanups x86/cpudetect x86/debug \n> x86/doc x86/header-fixes x86/mm x86/paravirt x86/pat x86/setup-v2 \n> x86/subarch x86/uaccess x86/urgent core/percpu\n> Trying simple merge with 2d4d57db692ea790e185656516e6ebe8791f1788\n> Trying simple merge with a448720ca3248e8a7a426336885549d6e923fd8e\n> Simple merge did not work, trying automatic merge.\n> Auto-merging arch/x86/include/asm/io.h\n> Auto-merging arch/x86/include/asm/spinlock.h\n> Auto-merging arch/x86/kernel/mpparse.c\n> Auto-merging arch/x86/kernel/setup_percpu.c\n> Auto-merging arch/x86/mm/init_32.c\n> Trying simple merge with b38b0665905538e76e26f2a4c686179abb1f69f6\n> Simple merge did not work, trying automatic merge.\n> Auto-merging arch/x86/kernel/cpu/common.c\n> Auto-merging arch/x86/kernel/cpu/intel.c\n> Auto-merging arch/x86/mm/pat.c\n> Trying simple merge with d5e397cb49b53381e4c99a064ca733c665646de8\n> Trying simple merge with e56d0cfe7790fd3218ae4f6aae1335547fea8763\n> Trying simple merge with dbca1df48e89d8aa59254fdc10ef16c16e73d94e\n> Trying simple merge with fb746d0e1365b7472ccc4c3d5b0672b34a092d0b\n> Trying simple merge with 6522869c34664dd5f05a0a327e93915b1281c90d\n> Simple merge did not work, trying automatic merge.\n> Auto-merging arch/x86/include/asm/paravirt.h\n> Trying simple merge with d639bab8da86d330493487e8c0fea8ca31f53427\n> Simple merge did not work, trying automatic merge.\n> Auto-merging arch/x86/include/asm/io.h\n> Auto-merging arch/x86/mm/ioremap.c\n> Trying simple merge with 042cbaf88ab48e11afb725541e3c2cbf5b483680\n> Trying simple merge with 5662a2f8e7313f78d6b17ab383f3e4f04971c335\n> Trying simple merge with 3b4b75700a245d0d48fc52a4d2f67d3155812aba\n> Simple merge did not work, trying automatic merge.\n> Auto-merging arch/x86/kernel/signal.c\n> Trying simple merge with bf3647c44bc76c43c4b2ebb4c37a559e899ac70e\n> Simple merge did not work, trying automatic merge.\n> Auto-merging arch/x86/kernel/cpu/intel.c\n> Trying simple merge with 4369f1fb7cd4cf777312f43e1cb9aa5504fc4125\n> /usr/libexec/git-core/git-merge-octopus: line 52: 26758 Segmentation fault      \n> git read-tree -u -m --aggressive $common $MRT $SHA1\n> Merge with strategy octopus failed.\n> earth4:~/tip> \n\nCurrent master (a34a9dbbc) with the following patch should not\nsegfault anymore (it doesn't here), but I don't know where the\nmagic number six is coming from. :-/\n\ndiff --git a/unpack-trees.c b/unpack-trees.c\nindex 16bc2ca..4b02fbf 100644\n--- a/unpack-trees.c\n+++ b/unpack-trees.c\n@@ -8,6 +8,8 @@\n #include \"progress.h\"\n #include \"refs.h\"\n \n+#define STAGES (5 + 1)\n+\n /*\n  * Error messages expected by scripts out of plumbing commands such as\n  * read-tree.  Non-scripted Porcelain is not required to use these messages\n@@ -143,7 +145,7 @@ static inline int call_unpack_fn(struct cache_entry **src, struct unpack_trees_o\n \n static int unpack_index_entry(struct cache_entry *ce, struct unpack_trees_options *o)\n {\n-\tstruct cache_entry *src[5] = { ce, };\n+\tstruct cache_entry *src[STAGES] = { ce, };\n \n \to->pos++;\n \tif (ce_stage(ce)) {\n@@ -240,7 +242,7 @@ static struct cache_entry *create_ce_entry(const struct traverse_info *info, con\n \treturn ce;\n }\n \n-static int unpack_nondirectories(int n, unsigned long mask, unsigned long dirmask, struct cache_entry *src[5],\n+static int unpack_nondirectories(int n, unsigned long mask, unsigned long dirmask, struct cache_entry *src[STAGES],\n \tconst struct name_entry *names, const struct traverse_info *info)\n {\n \tint i;\n@@ -291,7 +293,7 @@ static int unpack_nondirectories(int n, unsigned long mask, unsigned long dirmas\n \n static int unpack_callback(int n, unsigned long mask, unsigned long dirmask, struct name_entry *names, struct traverse_info *info)\n {\n-\tstruct cache_entry *src[5] = { NULL, };\n+\tstruct cache_entry *src[STAGES] = { NULL, };\n \tstruct unpack_trees_options *o = info->data;\n \tconst struct name_entry *p = names;\n \n@@ -728,7 +730,7 @@ int threeway_merge(struct cache_entry **stages, struct unpack_trees_options *o)\n {\n \tstruct cache_entry *index;\n \tstruct cache_entry *head;\n-\tstruct cache_entry *remote = stages[o->head_idx + 1];\n+\tstruct cache_entry *remote;\n \tint count;\n \tint head_match = 0;\n \tint remote_match = 0;\n@@ -755,6 +757,9 @@ int threeway_merge(struct cache_entry **stages, struct unpack_trees_options *o)\n \t\thead = NULL;\n \t}\n \n+\tif (o->head_idx + 1 >= STAGES)\n+\t\tdie(\"Too many stages (internal error)\");\n+\tremote = stages[o->head_idx + 1];\n \tif (remote == o->df_conflict_entry) {\n \t\tdf_conflict_remote = 1;\n \t\tremote = NULL;\n"},{"id":"102514","messageId":"20090129223410.GA1465@elte.hu","threadId":"17430","inReplyTo":"7vfxj1eqh6.fsf@gitster.siamese.dyndns.org","subject":"Re: Something weird is happening...","fromName":"Ingo Molnar","fromEmail":"mingo@elte.hu","sentAt":"2009-01-29T22:34:10Z","receivedAt":"2009-01-29T22:34:10Z","isPatch":false,"sender":{"key":"mingo@elte.hu","avatar":null},"body":"\n* Junio C Hamano <gitster@pobox.com> wrote:\n\n> But that is just a conjecture from a cursory looking at the current \n> code. I do not remember (or did not know from the beginning) some \n> details of it. And that is why I asked you if \"git fsck --full\" reports \n> it missing in my earlier response to you.\n\nsorry i did not follow up on that detail. I ran --full yesterday already \n(before we reported this), and besides taking a lot longer to finish it \nreported the same screenful of problems.\n\nShould i send the output of it? (i started it, it will take some time to \nfinish)\n\n\tIngo\n"},{"id":"102515","messageId":"20090129223529.GB1465@elte.hu","threadId":"17430","inReplyTo":"49822944.8000103@zytor.com","subject":"Re: Something weird is happening...","fromName":"Ingo Molnar","fromEmail":"mingo@elte.hu","sentAt":"2009-01-29T22:35:29Z","receivedAt":"2009-01-29T22:35:29Z","isPatch":false,"sender":{"key":"mingo@elte.hu","avatar":null},"body":"\n* H. Peter Anvin <hpa@zytor.com> wrote:\n\n>> But it still does the connectivity check fully from your refs.  And if \n>> it finds an object that ought to be reachable from your refs that it \n>> hasn't validated, it gives the \"missing\" warning above.  There is a \n>> check to exclude objects in packs when running \"git fsck\" without \n>> --full from this warning but I do not see a corresponding exclusion of \n>> objects that were borrowed from your neighbour which we didn't check \n>> either.\n>>\n>> But that is just a conjecture from a cursory looking at the current \n>> code. I do not remember (or did not know from the beginning) some \n>> details of it. And that is why I asked you if \"git fsck --full\" reports \n>> it missing in my earlier response to you.\n>\n> Just tried it, it doesn't.  So I guess things are OK.\n\nhm, it reported missing items here - but maybe i misremembered that. \nRe-running it currently. (takes quite a while)\n\n\tIngo\n"},{"id":"102516","messageId":"49822F68.9000106@zytor.com","threadId":"17430","inReplyTo":"20090129223410.GA1465@elte.hu","subject":"Re: Something weird is happening...","fromName":"H. Peter Anvin","fromEmail":"hpa@zytor.com","sentAt":"2009-01-29T22:36:24Z","receivedAt":"2009-01-29T22:36:24Z","isPatch":false,"sender":{"key":"hpa@zytor.com","avatar":null},"body":"Ingo Molnar wrote:\n> * Junio C Hamano <gitster@pobox.com> wrote:\n> \n>> But that is just a conjecture from a cursory looking at the current \n>> code. I do not remember (or did not know from the beginning) some \n>> details of it. And that is why I asked you if \"git fsck --full\" reports \n>> it missing in my earlier response to you.\n> \n> sorry i did not follow up on that detail. I ran --full yesterday already \n> (before we reported this), and besides taking a lot longer to finish it \n> reported the same screenful of problems.\n> \n> Should i send the output of it? (i started it, it will take some time to \n> finish)\n\nI didn't get the \"missing\" message with git fsck --full.  I get the \n\"dangling\" messages, still, but that is more or less expected.\n\n\t-hpa\n"},{"id":"102518","messageId":"498231EA.3030801@zytor.com","threadId":"17430","inReplyTo":"20090129224357.GA18471@elte.hu","subject":"Re: Something weird is happening...","fromName":"H. Peter Anvin","fromEmail":"hpa@zytor.com","sentAt":"2009-01-29T22:47:06Z","receivedAt":"2009-01-29T22:47:06Z","isPatch":false,"sender":{"key":"hpa@zytor.com","avatar":null},"body":"Ingo Molnar wrote:\n> \n> So the repo itself is fine, correct?\n> \n\nLooks like it.\n\n\t-hpa\n"},{"id":"102521","messageId":"7vvdrxd8jz.fsf@gitster.siamese.dyndns.org","threadId":"17430","inReplyTo":"498231EA.3030801@zytor.com","subject":"Re: Something weird is happening...","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2009-01-29T22:57:52Z","receivedAt":"2009-01-29T22:57:52Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"\"H. Peter Anvin\" <hpa@zytor.com> writes:\n\n> Ingo Molnar wrote:\n>>\n>> So the repo itself is fine, correct?\n>>\n>\n> Looks like it.\n\nCorrect.  It looks like \"fsck\" without --full is misreporting, which is\nsomething we should find a fix on our end.\n\nI am not sure how old this bug is (nor if I can make Linus admit it is\neven a bug---I suspect the code that is involved in this did not change\nthat much over time).\n"},{"id":"102522","messageId":"alpine.LNX.1.00.0901291731320.19665@iabervon.org","threadId":"17430","inReplyTo":"49822B91.6070303@lsrfire.ath.cx","subject":"Re: Something weird is happening...","fromName":"Daniel Barkalow","fromEmail":"barkalow@iabervon.org","sentAt":"2009-01-29T23:01:16Z","receivedAt":"2009-01-29T23:01:16Z","isPatch":false,"sender":{"key":"barkalow@iabervon.org","avatar":"https://avatars.githubusercontent.com/u/55364219?v=4"},"body":"On Thu, 29 Jan 2009, René Scharfe wrote:\n\n> Current master (a34a9dbbc) with the following patch should not\n> segfault anymore (it doesn't here), but I don't know where the\n> magic number six is coming from. :-/\n\nLooks like octopus is using multiple merge bases directly, rather than \ncombining them using merge-recursive. The merge-recursive concept turned \nout to be superior, and we kind of left multiple merge base support \nhanging. We should probably remove the old support and switch octopus to \nthe better way.\n\nMy guess is that 6 is just that there happen to be 3 merge bases for this \nparticular merge (plus the merge results and the two sides).\n\n\t-Daniel\n*This .sig left intentionally blank*"},{"id":"102524","messageId":"alpine.LFD.2.00.0901291512260.3054@localhost.localdomain","threadId":"17430","inReplyTo":"7vvdrxd8jz.fsf@gitster.siamese.dyndns.org","subject":"Re: Something weird is happening...","fromName":"Linus Torvalds","fromEmail":"torvalds@linux-foundation.org","sentAt":"2009-01-29T23:21:55Z","receivedAt":"2009-01-29T23:21:55Z","isPatch":false,"sender":{"key":"torvalds@linux-foundation.org","avatar":"https://avatars.githubusercontent.com/u/1024025?v=4"},"body":"\n\nOn Thu, 29 Jan 2009, Junio C Hamano wrote:\n> \n> I am not sure how old this bug is (nor if I can make Linus admit it is\n> even a bug---I suspect the code that is involved in this did not change\n> that much over time).\n\nI'll happily admit that it's a bug.\n\nI think our \"fsck\" logic kind of sucks - the default version really skips \ntoo damn much in the name of being fast and only look at loose objects, \nand --full is _so_ anal that it's silly and overkill for almost \neverything.\n\nWe probably should have a middle ground (that should be the default), \nwhich does at least somewhat proper reachability analysis, checks \nalternates, and make the current \"only check local loose objects\" be an \noption like \"git fsck --loose\" (or \"--local\").\n\nOut current \"git fsck --full\" is even mis-documented. The built-in help \nsays that it means \"also consider alternate objects\", but that's just a \nsmall part of what it does. It _also_ verifies the pack-files, and that's \nactually the really expensive part.\n\nSo \"check_full\" turns on _everything_, but some things that it turns on \nshould be turned on already by default (the \"alternates\" directory check), \nwhile other parts of --full are just too expensive to ever be default (the \npack-file check).\n\n\t\t\tLinus\n"},{"id":"102554","messageId":"7veiylb1in.fsf_-_@gitster.siamese.dyndns.org","threadId":"17430","inReplyTo":"alpine.LFD.2.00.0901291512260.3054@localhost.localdomain","subject":"[PATCH 1/2] fsck: HEAD is part of refs","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2009-01-30T09:12:48Z","receivedAt":"2009-01-30T09:12:48Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"By default we looked at all refs but not HEAD.  The only thing that\nmade fsck not lose sight of comments that are only reachable from a\ndetached HEAD was the reflog for the HEAD.\n\nThis fixes it, with a new test.\n\nSigned-off-by: Junio C Hamano <gitster@pobox.com>\n---\n\n * This is unrelated to Peter's \"missing blob\", but should be an obviously\n   right thing to do. \n\n builtin-fsck.c  |   13 ++++++++-----\n t/t1450-fsck.sh |   18 ++++++++++++++++++\n 2 files changed, 26 insertions(+), 5 deletions(-)\n create mode 100755 t/t1450-fsck.sh\n\ndiff --git a/builtin-fsck.c b/builtin-fsck.c\nindex aecc828..2cfff43 100644\n--- a/builtin-fsck.c\n+++ b/builtin-fsck.c\n@@ -23,6 +23,7 @@ static int check_full;\n static int check_strict;\n static int keep_cache_objects;\n static unsigned char head_sha1[20];\n+static const char *head_points_at;\n static int errors_found;\n static int write_lost_and_found;\n static int verbose;\n@@ -473,6 +474,8 @@ static int fsck_handle_ref(const char *refname, const unsigned char *sha1, int f\n \n static void get_default_heads(void)\n {\n+\tif (head_points_at && !is_null_sha1(head_sha1))\n+\t\tfsck_handle_ref(\"HEAD\", head_sha1, 0, NULL);\n \tfor_each_ref(fsck_handle_ref, NULL);\n \tif (include_reflogs)\n \t\tfor_each_reflog(fsck_handle_reflog, NULL);\n@@ -512,14 +515,13 @@ static void fsck_object_dir(const char *path)\n \n static int fsck_head_link(void)\n {\n-\tunsigned char sha1[20];\n \tint flag;\n \tint null_is_error = 0;\n-\tconst char *head_points_at = resolve_ref(\"HEAD\", sha1, 0, &flag);\n \n \tif (verbose)\n \t\tfprintf(stderr, \"Checking HEAD link\\n\");\n \n+\thead_points_at = resolve_ref(\"HEAD\", head_sha1, 0, &flag);\n \tif (!head_points_at)\n \t\treturn error(\"Invalid HEAD\");\n \tif (!strcmp(head_points_at, \"HEAD\"))\n@@ -528,7 +530,7 @@ static int fsck_head_link(void)\n \telse if (prefixcmp(head_points_at, \"refs/heads/\"))\n \t\treturn error(\"HEAD points to something strange (%s)\",\n \t\t\t     head_points_at);\n-\tif (is_null_sha1(sha1)) {\n+\tif (is_null_sha1(head_sha1)) {\n \t\tif (null_is_error)\n \t\t\treturn error(\"HEAD: detached HEAD points at nothing\");\n \t\tfprintf(stderr, \"notice: HEAD points to an unborn branch (%s)\\n\",\n@@ -624,8 +626,9 @@ int cmd_fsck(int argc, const char **argv, const char *prefix)\n \theads = 0;\n \tfor (i = 0; i < argc; i++) {\n \t\tconst char *arg = argv[i];\n-\t\tif (!get_sha1(arg, head_sha1)) {\n-\t\t\tstruct object *obj = lookup_object(head_sha1);\n+\t\tunsigned char sha1[20];\n+\t\tif (!get_sha1(arg, sha1)) {\n+\t\t\tstruct object *obj = lookup_object(sha1);\n \n \t\t\t/* Error is printed by lookup_object(). */\n \t\t\tif (!obj)\ndiff --git a/t/t1450-fsck.sh b/t/t1450-fsck.sh\nnew file mode 100755\nindex 0000000..5166566\n--- /dev/null\n+++ b/t/t1450-fsck.sh\n@@ -0,0 +1,18 @@\n+#!/bin/sh\n+\n+test_description='git fsck random collection of tests'\n+\n+. ./test-lib.sh\n+\n+test_expect_success setup '\n+\ttest_commit A &&\n+\tgit checkout HEAD^0 &&\n+\ttest_commit B &&\n+\tgit reflog expire --expire=now --all\n+'\n+\n+test_expect_success 'HEAD is part of refs' '\n+\ttest 0 = $(git fsck | wc -l)\n+'\n+\n+test_done\n-- \n1.6.1.2.312.g5be3c\n"},{"id":"102555","messageId":"7vd4e5b1i7.fsf_-_@gitster.siamese.dyndns.org","threadId":"17430","inReplyTo":"alpine.LFD.2.00.0901291512260.3054@localhost.localdomain","subject":"[PATCH 2/2] fsck: check loose objects from alternate object stores by default","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2009-01-30T09:13:04Z","receivedAt":"2009-01-30T09:13:04Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"\"git fsck\" used to validate only loose objects that are local and nothing\nelse by default.  This is not just too little when a repository is\nborrowing objects from other object stores, but also caused the\nconnectivity check to mistakenly declare loose objects borrowed from them\nto be missing.\n\nThe rationale behind the default mode that validates only loose objects is\nbecause these objects are still young and more unlikely to have been\npushed to other repositories yet.  That holds for loose objects borrowed\nfrom alternate object stores as well.\n\nSigned-off-by: Junio C Hamano <gitster@pobox.com>\n---\n\n * This implements your earlier suggestion.  We might want to say where\n   the corrupt object was found when fsck_sha1() reports problems, but\n   that is an issue that already exists when the command is run with\n   --full.\n\n builtin-fsck.c  |   21 ++++++++++++---------\n t/t1450-fsck.sh |   16 ++++++++++++++--\n 2 files changed, 26 insertions(+), 11 deletions(-)\n\ndiff --git a/builtin-fsck.c b/builtin-fsck.c\nindex 2cfff43..64dffa5 100644\n--- a/builtin-fsck.c\n+++ b/builtin-fsck.c\n@@ -586,6 +586,7 @@ static struct option fsck_opts[] = {\n int cmd_fsck(int argc, const char **argv, const char *prefix)\n {\n \tint i, heads;\n+\tstruct alternate_object_database *alt;\n \n \terrors_found = 0;\n \n@@ -597,17 +598,19 @@ int cmd_fsck(int argc, const char **argv, const char *prefix)\n \n \tfsck_head_link();\n \tfsck_object_dir(get_object_directory());\n+\n+\tprepare_alt_odb();\n+\tfor (alt = alt_odb_list; alt; alt = alt->next) {\n+\t\tchar namebuf[PATH_MAX];\n+\t\tint namelen = alt->name - alt->base;\n+\t\tmemcpy(namebuf, alt->base, namelen);\n+\t\tnamebuf[namelen - 1] = 0;\n+\t\tfsck_object_dir(namebuf);\n+\t}\n+\n \tif (check_full) {\n-\t\tstruct alternate_object_database *alt;\n \t\tstruct packed_git *p;\n-\t\tprepare_alt_odb();\n-\t\tfor (alt = alt_odb_list; alt; alt = alt->next) {\n-\t\t\tchar namebuf[PATH_MAX];\n-\t\t\tint namelen = alt->name - alt->base;\n-\t\t\tmemcpy(namebuf, alt->base, namelen);\n-\t\t\tnamebuf[namelen - 1] = 0;\n-\t\t\tfsck_object_dir(namebuf);\n-\t\t}\n+\n \t\tprepare_packed_git();\n \t\tfor (p = packed_git; p; p = p->next)\n \t\t\t/* verify gives error messages itself */\ndiff --git a/t/t1450-fsck.sh b/t/t1450-fsck.sh\nindex 5166566..6e64e44 100755\n--- a/t/t1450-fsck.sh\n+++ b/t/t1450-fsck.sh\n@@ -5,9 +5,9 @@ test_description='git fsck random collection of tests'\n . ./test-lib.sh\n \n test_expect_success setup '\n-\ttest_commit A &&\n+\ttest_commit A fileA one &&\n \tgit checkout HEAD^0 &&\n-\ttest_commit B &&\n+\ttest_commit B fileB two &&\n \tgit reflog expire --expire=now --all\n '\n \n@@ -15,4 +15,16 @@ test_expect_success 'HEAD is part of refs' '\n \ttest 0 = $(git fsck | wc -l)\n '\n \n+test_expect_success 'loose objects borrowed from alternate are not missing' '\n+\tmkdir another &&\n+\t(\n+\t\tcd another &&\n+\t\tgit init &&\n+\t\techo ../../../.git/objects >.git/objects/info/alternates &&\n+\t\ttest_commit C fileC one &&\n+\t\tgit fsck >out &&\n+\t\t! grep \"missing blob\" out\n+\t)\n+'\n+\n test_done\n-- \n1.6.1.2.312.g5be3c\n"},{"id":"102556","messageId":"4982C7FA.20107@viscovery.net","threadId":"17430","inReplyTo":"7veiylb1in.fsf_-_@gitster.siamese.dyndns.org","subject":"Re: [PATCH 1/2] fsck: HEAD is part of refs","fromName":"Johannes Sixt","fromEmail":"j.sixt@viscovery.net","sentAt":"2009-01-30T09:27:22Z","receivedAt":"2009-01-30T09:27:22Z","isPatch":true,"sender":{"key":"j6t@kdbg.org","avatar":"https://avatars.githubusercontent.com/u/14810926?v=4"},"body":"Junio C Hamano schrieb:\n> By default we looked at all refs but not HEAD.  The only thing that\n> made fsck not lose sight of comments that are only reachable from a\n> detached HEAD was the reflog for the HEAD.\n> \n> This fixes it, with a new test.\n[...]\n> +test_expect_success setup '\n> +\ttest_commit A &&\n> +\tgit checkout HEAD^0 &&\n> +\ttest_commit B &&\n> +\tgit reflog expire --expire=now --all\n> +'\n> +\n> +test_expect_success 'HEAD is part of refs' '\n> +\ttest 0 = $(git fsck | wc -l)\n\nI'm scratching my head over this. This test succeeds even without the\nchange... (Tested with a34a9db.)\n\n-- Hannes\n"},{"id":"102621","messageId":"alpine.DEB.1.00.0901301746370.3586@pacific.mpi-cbg.de","threadId":"17430","inReplyTo":"7veiylb1in.fsf_-_@gitster.siamese.dyndns.org","subject":"Re: [PATCH 1/2] fsck: HEAD is part of refs","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2009-01-30T16:47:35Z","receivedAt":"2009-01-30T16:47:35Z","isPatch":true,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi,\n\nOn Fri, 30 Jan 2009, Junio C Hamano wrote:\n\n> By default we looked at all refs but not HEAD.  The only thing that\n> made fsck not lose sight of comments that are only reachable from a\n> detached HEAD was the reflog for the HEAD.\n\nWhen fixing the revision machinery to imply HEAD with --all, I thought of \nfsck, too, but forgot to check if it does actually use the revision \nwalker.\n\nSorry about this,\nDscho\n"},{"id":"102701","messageId":"4984628E.8090600@lsrfire.ath.cx","threadId":"17430","inReplyTo":"20090129120539.GA26975@elte.hu","subject":"[PATCH] merge: fix out-of-bounds memory access","fromName":"René Scharfe","fromEmail":"rene.scharfe@lsrfire.ath.cx","sentAt":"2009-01-31T14:39:10Z","receivedAt":"2009-01-31T14:39:10Z","isPatch":true,"sender":{"key":"l.s.r@web.de","avatar":"https://avatars.githubusercontent.com/u/26122331?v=4"},"body":"The following on top of master lets git finish the merge without segfault\n(reporting a merge conflict) and valgrind doesn't find an more memory\nerrors here.  Can you confirm that, Ingo?\n\n-- 8< --\nThe parameter n of unpack_callback() can have a value of up to\nMAX_UNPACK_TREES.  The check at the top of unpack_trees() (its only\n(indirect) caller) makes sure it cannot exceed this limit.\n\nunpack_callback() passes it and the array src to unpack_nondirectories(),\nwhich has this loop:\n\n\tfor (i = 0; i < n; i++) {\n\t\t/* ... */\n\t\tsrc[i + o->merge] = o->df_conflict_entry;\n\no->merge can be 0 or 1, so unpack_nondirectories() potentially accesses\nthe array src at index MAX_UNPACK_TREES.  This patch makes it big enough.\n\nReported-by: Ingo Molnar <mingo@elte.hu>\nSigned-off-by: Rene Scharfe <rene.scharfe@lsrfire.ath.cx>\n---\n unpack-trees.c |    9 ++++++---\n 1 files changed, 6 insertions(+), 3 deletions(-)\n\ndiff --git a/unpack-trees.c b/unpack-trees.c\nindex 16bc2ca..e547282 100644\n--- a/unpack-trees.c\n+++ b/unpack-trees.c\n@@ -240,8 +240,11 @@ static struct cache_entry *create_ce_entry(const struct traverse_info *info, con\n \treturn ce;\n }\n \n-static int unpack_nondirectories(int n, unsigned long mask, unsigned long dirmask, struct cache_entry *src[5],\n-\tconst struct name_entry *names, const struct traverse_info *info)\n+static int unpack_nondirectories(int n, unsigned long mask,\n+\t\t\t\t unsigned long dirmask,\n+\t\t\t\t struct cache_entry **src,\n+\t\t\t\t const struct name_entry *names,\n+\t\t\t\t const struct traverse_info *info)\n {\n \tint i;\n \tstruct unpack_trees_options *o = info->data;\n@@ -291,7 +294,7 @@ static int unpack_nondirectories(int n, unsigned long mask, unsigned long dirmas\n \n static int unpack_callback(int n, unsigned long mask, unsigned long dirmask, struct name_entry *names, struct traverse_info *info)\n {\n-\tstruct cache_entry *src[5] = { NULL, };\n+\tstruct cache_entry *src[MAX_UNPACK_TREES + 1] = { NULL, };\n \tstruct unpack_trees_options *o = info->data;\n \tconst struct name_entry *p = names;\n \n-- \n1.6.1\n"},{"id":"102716","messageId":"20090201064520.6117@nanako3.lavabit.com","threadId":"17430","inReplyTo":"7veiylb1in.fsf_-_@gitster.siamese.dyndns.org","subject":"Re: [PATCH 1/2] fsck: HEAD is part of refs","fromName":"Nanako Shiraishi","fromEmail":"nanako3@lavabit.com","sentAt":"2009-01-31T21:45:20Z","receivedAt":"2009-01-31T21:45:20Z","isPatch":true,"sender":{"key":"nanako3@lavabit.com","avatar":"https://gravatar.com/avatar/3777b9e201c5883a62b1a6fdf7c53f2d712d1d80989146063ea861e33aad72a8?d=mp&s=160"},"body":"Quoting Junio C Hamano <gitster@pobox.com>:\n\n> By default we looked at all refs but not HEAD.  The only thing that\n> made fsck not lose sight of comments that are only reachable from a\n> detached HEAD was the reflog for the HEAD.\n>\n> This fixes it, with a new test.\n>\n> Signed-off-by: Junio C Hamano <gitster@pobox.com>\n\nI think you meant to say commits, not comments.\n\n-- \nNanako Shiraishi\nhttp://ivory.ap.teacup.com/nanako3/\n"},{"id":"102727","messageId":"7v3aez3rlz.fsf@gitster.siamese.dyndns.org","threadId":"17430","inReplyTo":"4982C7FA.20107@viscovery.net","subject":"Re: [PATCH 1/2] fsck: HEAD is part of refs","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2009-02-01T00:53:12Z","receivedAt":"2009-02-01T00:53:12Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Johannes Sixt <j.sixt@viscovery.net> writes:\n\n> Junio C Hamano schrieb:\n>> By default we looked at all refs but not HEAD.  The only thing that\n>> made fsck not lose sight of comments that are only reachable from a\n>> detached HEAD was the reflog for the HEAD.\n>> \n>> This fixes it, with a new test.\n> [...]\n>> +test_expect_success setup '\n>> +\ttest_commit A &&\n>> +\tgit checkout HEAD^0 &&\n>> +\ttest_commit B &&\n>> +\tgit reflog expire --expire=now --all\n>> +'\n>> +\n>> +test_expect_success 'HEAD is part of refs' '\n>> +\ttest 0 = $(git fsck | wc -l)\n>\n> I'm scratching my head over this. This test succeeds even without the\n> change... (Tested with a34a9db.)\n\nYou are right.  I forgot that test_commit creates an extra tag.  By adding\n\n\tgit tag -d B &&\n\nafter \"test_commit B &&\", you would expose the issue in the existing code.\n"},{"id":"102731","messageId":"7vhc3f2cux.fsf@gitster.siamese.dyndns.org","threadId":"17430","inReplyTo":"20090201064520.6117@nanako3.lavabit.com","subject":"Re: [PATCH 1/2] fsck: HEAD is part of refs","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2009-02-01T00:57:10Z","receivedAt":"2009-02-01T00:57:10Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Nanako Shiraishi <nanako3@lavabit.com> writes:\n\n> Quoting Junio C Hamano <gitster@pobox.com>:\n>\n>> By default we looked at all refs but not HEAD.  The only thing that\n>> made fsck not lose sight of comments that are only reachable from a\n>> detached HEAD was the reflog for the HEAD.\n>>\n>> This fixes it, with a new test.\n>>\n>> Signed-off-by: Junio C Hamano <gitster@pobox.com>\n>\n> I think you meant to say commits, not comments.\n\nI'll amend when I fix the broken test J6t pointed out.\n"},{"id":"102735","messageId":"7vk58b0wox.fsf@gitster.siamese.dyndns.org","threadId":"17430","inReplyTo":"bd6139dc0901290545s1a5ba310u549338e823762ae1@mail.gmail.com","subject":"Re: Something weird is happening...","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2009-02-01T01:31:42Z","receivedAt":"2009-02-01T01:31:42Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Sverre Rabbelier <srabbelier@gmail.com> writes:\n\n> On Thu, Jan 29, 2009 at 07:56, Junio C Hamano <gitster@pobox.com> wrote:\n>>> Okay, what is going on here?\n>\n> Is this perhaps related to the problem the github guys were having,\n> its sounds similar, problem not showing up until after upgrade,\n> missing objects, no?\n\nI do not think so.  The push problem does not lead to any repository\ncorruption, and does not have anything to do with the fsck misreporting a\nblob that exists in an alternate object store as missing, either.\n\n.\n"}]}