{"thread":{"id":"3320","subject":"git-bisect problem","startedAt":"2006-02-13T08:25:02Z","lastAt":"2006-02-14T01:52:31Z","messageCount":23,"participants":["Andrew Morton","Junio C Hamano","Ryan Anderson","Fernando J. Pereda","Luben Tuikov","Joshua N Pritikin","Linus Torvalds","Petr Baudis"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"16029","messageId":"20060213002502.5c23122c.akpm@osdl.org","threadId":"3320","inReplyTo":null,"subject":"git-bisect problem","fromName":"Andrew Morton","fromEmail":"akpm@osdl.org","sentAt":"2006-02-13T08:25:02Z","receivedAt":"2006-02-13T08:25:02Z","isPatch":false,"sender":{"key":"akpm@osdl.org","avatar":null},"body":"\nI've been trying to locate an ipw2200 regression in Jeff's tree\n(git+ssh://master.kernel.org/pub/scm/linux/kernel/git/jgarzik/netdev-2.6.git#ALL)\nand it ended up leading me to \n\n826eeb53a6f264842200d3311d69107d2eb25f5e is first bad commit\ndiff-tree 826eeb53a6f264842200d3311d69107d2eb25f5e (from 33052057e3e2db7f37fc78aa3f25c98f7e989fae)\nAuthor: Linus Torvalds \nDate: Thu Feb 2 22:03:08 2006 -0800\n\n Linux v2.6.16-rc2\n\nwhich wasn't very useful.\n\nI don't _think_ I screwed anything up.\n\ngit-bisect start\n# good: [2664b25051f7ab96b22b199aa2f5ef6a949a4296] Linux v2.6.16-rc1\ngit-bisect good 2664b25051f7ab96b22b199aa2f5ef6a949a4296\n# bad: [826eeb53a6f264842200d3311d69107d2eb25f5e] Linux v2.6.16-rc2\ngit-bisect bad 826eeb53a6f264842200d3311d69107d2eb25f5e\n# good: [10379a25fee8ddc8698d2f6c54ccedd4664c2941] Merge master.kernel.org:/pub/scm/linux/kernel/git/davej/agpgart\ngit-bisect good 10379a25fee8ddc8698d2f6c54ccedd4664c2941\n# good: [9a2dba4b4912b493070cbc170629fdbf440b01d7] slab: rename ac_data to cpu_cache_get\ngit-bisect good 9a2dba4b4912b493070cbc170629fdbf440b01d7\n# good: [9ad11ab48b1ad618bf47076e9e579f267f5306c2] compat: fix compat_sys_openat and friends\ngit-bisect good 9ad11ab48b1ad618bf47076e9e579f267f5306c2\n# good: [1494a92f4c2b1d5abdaa1f823dd19f797bb137de] [ALSA] hda-codec - Fix typos in alc882 model table\ngit-bisect good 1494a92f4c2b1d5abdaa1f823dd19f797bb137de\n# good: [9fdb62af92c741addbea15545f214a6e89460865] [ACPI] merge 3549 4320 4485 4588 4980 5483 5651 acpica asus fops pnpacpi branches into release\ngit-bisect good 9fdb62af92c741addbea15545f214a6e89460865\n# good: [cf41f8ac386e8d62122e7e394b4c6b3e3ab30ede] Merge branch 'drm-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/airlied/drm-2.6\ngit-bisect good cf41f8ac386e8d62122e7e394b4c6b3e3ab30ede\n# good: [00b464debf0038b1628996065f0be564ccfbfd86] SUNRPC: Remove obsolete rpcauth #defines\ngit-bisect good 00b464debf0038b1628996065f0be564ccfbfd86\n# good: [35849c75d7750a254119c1a4b88c90156919df2a] md: Add sysfs access to raid6 stripe cache size\ngit-bisect good 35849c75d7750a254119c1a4b88c90156919df2a\n# good: [33052057e3e2db7f37fc78aa3f25c98f7e989fae] Merge branch 'master' of git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6\ngit-bisect good 33052057e3e2db7f37fc78aa3f25c98f7e989fae\n"},{"id":"16030","messageId":"7virrj1v44.fsf@assigned-by-dhcp.cox.net","threadId":"3320","inReplyTo":"20060213002502.5c23122c.akpm@osdl.org","subject":"Re: git-bisect problem","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2006-02-13T09:11:23Z","receivedAt":"2006-02-13T09:11:23Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Andrew Morton writes:\n\n> I've been trying to locate an ipw2200 regression in Jeff's tree\n> (git+ssh://master.kernel.org/pub/scm/linux/kernel/git/jgarzik/netdev-2.6.git#ALL)\n> and it ended up leading me to \n>\n> 826eeb53a6f264842200d3311d69107d2eb25f5e is first bad commit\n> diff-tree 826eeb53a6f264842200d3311d69107d2eb25f5e (from 33052057e3e2db7f37fc78aa3f25c98f7e989fae)\n> Author: Linus Torvalds \n> Date: Thu Feb 2 22:03:08 2006 -0800\n>\n> Linux v2.6.16-rc2\n>\n> which wasn't very useful.\n>\n> I don't _think_ I screwed anything up.\n>\n> git-bisect start\n> # good: [2664b25051f7ab96b22b199aa2f5ef6a949a4296] Linux v2.6.16-rc1\n> git-bisect good 2664b25051f7ab96b22b199aa2f5ef6a949a4296\n> # bad: [826eeb53a6f264842200d3311d69107d2eb25f5e] Linux v2.6.16-rc2\n> git-bisect bad 826eeb53a6f264842200d3311d69107d2eb25f5e\n> # good: [10379a25fee8ddc8698d2f6c54ccedd4664c2941] Merge master.kernel.org:/pub/scm/linux/kernel/git/davej/agpgart\n> git-bisect good 10379a25fee8ddc8698d2f6c54ccedd4664c2941\n> # good: [9a2dba4b4912b493070cbc170629fdbf440b01d7] slab: rename ac_data to cpu_cache_get\n> git-bisect good 9a2dba4b4912b493070cbc170629fdbf440b01d7\n> # good: [9ad11ab48b1ad618bf47076e9e579f267f5306c2] compat: fix compat_sys_openat and friends\n> git-bisect good 9ad11ab48b1ad618bf47076e9e579f267f5306c2\n> # good: [1494a92f4c2b1d5abdaa1f823dd19f797bb137de] [ALSA] hda-codec - Fix typos in alc882 model table\n> git-bisect good 1494a92f4c2b1d5abdaa1f823dd19f797bb137de\n> # good: [9fdb62af92c741addbea15545f214a6e89460865] [ACPI] merge 3549 4320 4485 4588 4980 5483 5651 acpica asus fops pnpacpi branches into release\n> git-bisect good 9fdb62af92c741addbea15545f214a6e89460865\n> # good: [cf41f8ac386e8d62122e7e394b4c6b3e3ab30ede] Merge branch 'drm-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/airlied/drm-2.6\n> git-bisect good cf41f8ac386e8d62122e7e394b4c6b3e3ab30ede\n\nAt this point, looking at \"git bisect visualize\" shows that\nbisect point is at \"SUNRPC: Remove obsolete rpcauth #defines\",\nand commits older than that are NFSv3, 4 SUNRPCs, 2 NLMs, and\nstops at \"[PATCH] kernel-doc: clean up the script (whitespace)\".\n\n> # good: [00b464debf0038b1628996065f0be564ccfbfd86] SUNRPC: Remove obsolete rpcauth #defines\n> git-bisect good 00b464debf0038b1628996065f0be564ccfbfd86\n\nAnd this is marked to be good -- it leaves:\n\n SUNPRC good\n SUNRPC NFSv3 00b464\n ...o---o---o---o---------o--------o\n / bad\n o---o---o---o---o---o v2.6.16-rc2\n good \n cf41f8 md md md md dm\n\n> # good: [35849c75d7750a254119c1a4b88c90156919df2a] md: Add sysfs access to raid6 stripe cache size\n> git-bisect good 35849c75d7750a254119c1a4b88c90156919df2a\n\nThen you mark the rightmost md to be good.\n\n good\n 00b464\n o---------o--------o\n / bad\n o---o v2.6.16-rc2\n good\n md dm\n\nSo at this point, assuming the bug is something that is\nbisectable, there are still three suspects:\n\n (1) dm (device-mapper log bitset: fix big endian)\n (2) the merge was screwed up \n (3) Linus did more than setting EXTRAVERSION in v2.6.16-rc2\n\n> # good: [33052057e3e2db7f37fc78aa3f25c98f7e989fae] Merge branch 'master' of git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6\n> git-bisect good 33052057e3e2db7f37fc78aa3f25c98f7e989fae\n\nAnd your test showed the merge one was good.\n\n good\n 330520\n o---------o--------o\n / bad\n o---o v2.6.16-rc2\n good\n md dm\n\nAs humans, we can tell that it is not very plausible that the\nEXTRAVERSION change caused whatever breakage you are chasing,\nbut sorry, from your log, I think bisect is doing the right\nthing.\n\nThe last stretch of the md/dm track does not seem to have much\nto do with ipw2200 (isn't that a wireless thing?), and the other\ntrack does not look card specific even though NFS and SUNRPC\nsounds networking related. If I have to guess:\n\n (0) the bug is not really reproducible;\n\n (1) an earlier part of bisection misrecorded bad as good;\n\n (2) older commits on these two tracks have subtle interaction,\n and the problem does not surface without such interaction\n (but that is not plausible because your test on the final\n \"merge\" should have shown the problem if that is the case);\n"},{"id":"16033","messageId":"20060213013205.4ba47836.akpm@osdl.org","threadId":"3320","inReplyTo":"7virrj1v44.fsf@assigned-by-dhcp.cox.net","subject":"Re: git-bisect problem","fromName":"Andrew Morton","fromEmail":"akpm@osdl.org","sentAt":"2006-02-13T09:32:05Z","receivedAt":"2006-02-13T09:32:05Z","isPatch":false,"sender":{"key":"akpm@osdl.org","avatar":null},"body":"Junio C Hamano wrote:\n>\n> As humans, we can tell that it is not very plausible that the\n> EXTRAVERSION change caused whatever breakage you are chasing,\n> but sorry, from your log, I think bisect is doing the right\n> thing.\n\nI don't think humans are well-suited to using git.\n\nMy current theory is that I was bisecting Linus's tree all along.\n\nWhat is the correct way in which to switch to git-netdev-all in preparation\nfor performing the bisection?\n"},{"id":"16034","messageId":"20060213093938.GC11053@mythryan2.michonline.com","threadId":"3320","inReplyTo":"20060213013205.4ba47836.akpm@osdl.org","subject":"Re: git-bisect problem","fromName":"Ryan Anderson","fromEmail":"ryan@michonline.com","sentAt":"2006-02-13T09:39:38Z","receivedAt":"2006-02-13T09:39:38Z","isPatch":false,"sender":{"key":"ryan@michonline.com","avatar":null},"body":"On Mon, Feb 13, 2006 at 01:32:05AM -0800, Andrew Morton wrote:\n> Junio C Hamano wrote:\n> >\n> > As humans, we can tell that it is not very plausible that the\n> > EXTRAVERSION change caused whatever breakage you are chasing,\n> > but sorry, from your log, I think bisect is doing the right\n> > thing.\n> \n> I don't think humans are well-suited to using git.\n> \n> My current theory is that I was bisecting Linus's tree all along.\n> \n> What is the correct way in which to switch to git-netdev-all in preparation\n> for performing the bisection?\n\nFirst, use \"git branch\" to show you what branches exist, the * will mark\nthe current one.\n\nThen \"git checkout $branch\" to switch to one that exists, or \"git\ncheckout -b $newbranch $sourcebranch\" to create a new branch starting\nfrom $sourcebranch (which can also be a random commit/tag/etc).\n\n-- \n\nRyan Anderson\n sometimes Pug Majere\n"},{"id":"16035","messageId":"20060213015146.26e6c09d.akpm@osdl.org","threadId":"3320","inReplyTo":"20060213093938.GC11053@mythryan2.michonline.com","subject":"Re: git-bisect problem","fromName":"Andrew Morton","fromEmail":"akpm@osdl.org","sentAt":"2006-02-13T09:51:46Z","receivedAt":"2006-02-13T09:51:46Z","isPatch":false,"sender":{"key":"akpm@osdl.org","avatar":null},"body":"Ryan Anderson wrote:\n>\n> On Mon, Feb 13, 2006 at 01:32:05AM -0800, Andrew Morton wrote:\n> > Junio C Hamano wrote:\n> > >\n> > > As humans, we can tell that it is not very plausible that the\n> > > EXTRAVERSION change caused whatever breakage you are chasing,\n> > > but sorry, from your log, I think bisect is doing the right\n> > > thing.\n> > \n> > I don't think humans are well-suited to using git.\n> > \n> > My current theory is that I was bisecting Linus's tree all along.\n> > \n> > What is the correct way in which to switch to git-netdev-all in preparation\n> > for performing the bisection?\n> \n> First, use \"git branch\" to show you what branches exist, the * will mark\n> the current one.\n> \n> Then \"git checkout $branch\" to switch to one that exists, or \"git\n> checkout -b $newbranch $sourcebranch\" to create a new branch starting\n> from $sourcebranch (which can also be a random commit/tag/etc).\n> \n\nYeah, am (ret)trying that.\n\nAssuming I find the bad commit, how do I extract it as a patch?\n\nI tried\n\ngit-format-patch -o ~/a 386093ef9a6c88576d8b418bf1c8616d5e410a20 git-netdev-all\n\nand that chewed 10 minutes CPU time and produced no output, so I killed it.\n"},{"id":"16036","messageId":"20060213095859.GA17115@ferdyx.org","threadId":"3320","inReplyTo":"20060213015146.26e6c09d.akpm@osdl.org","subject":"Re: git-bisect problem","fromName":"Fernando J. Pereda","fromEmail":"ferdy@ferdyx.org","sentAt":"2006-02-13T09:58:59Z","receivedAt":"2006-02-13T09:58:59Z","isPatch":false,"sender":{"key":"ferdy@ferdyx.org","avatar":"https://gravatar.com/avatar/96bf7c1ddf7ccd430255bd12d9d42b212dbc033b28c668a2bdf9c3995aa81e61?d=mp&s=160"},"body":"On Mon, Feb 13, 2006 at 01:51:46AM -0800, Andrew Morton wrote:\n| Assuming I find the bad commit, how do I extract it as a patch?\n| \n| I tried\n| \n| git-format-patch -o ~/a 386093ef9a6c88576d8b418bf1c8616d5e410a20 git-netdev-all\n| \n| and that chewed 10 minutes CPU time and produced no output, so I killed it.\n\nThis gives you the whole info about the commit, including a patch:\n\ngit cat-file commit 386093ef9a6c88576d8b418bf1c8616d5e410a20\n\nCheers,\nFerdy\n\n-- \nFernando J. Pereda Garcimartín\nGentoo Developer (Alpha,net-mail,mutt,git)\n20BB BDC3 761A 4781 E6ED ED0B 0A48 5B0C 60BD 28D4\n"},{"id":"16037","messageId":"7vbqxb1sho.fsf@assigned-by-dhcp.cox.net","threadId":"3320","inReplyTo":"20060213013205.4ba47836.akpm@osdl.org","subject":"Re: git-bisect problem","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2006-02-13T10:08:03Z","receivedAt":"2006-02-13T10:08:03Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Andrew Morton writes:\n\n>> As humans, we can tell that it is not very plausible that the\n>> EXTRAVERSION change caused whatever breakage you are chasing,\n>> but sorry, from your log, I think bisect is doing the right\n>> thing.\n>\n> I don't think humans are well-suited to using git.\n\nI did not mean that ;-). Git is not as smart as humans.\n\n> My current theory is that I was bisecting Linus's tree all along.\n\nSorry, I did not realize that was _not_ what you were doing.\nYour log started by saying 2.6.16-rc1 is good but 2.6.16-rc2 was\nnot, so I just assumed your bug was between those two.\n\nIf your suspect was merged between these two versions, then it\ndoes not matter which branch you were _on_ when you started to\nbisect. \n\nYou mark points that are good and bad, and wander around in the\ncommit DAG, trying to narrow down the distance between known\ngood points and bad points while bisecting, and during that, you\nare not really on _any_ branch.\n"},{"id":"16038","messageId":"20060213101443.GD11053@mythryan2.michonline.com","threadId":"3320","inReplyTo":"20060213015146.26e6c09d.akpm@osdl.org","subject":"Re: git-bisect problem","fromName":"Ryan Anderson","fromEmail":"ryan@michonline.com","sentAt":"2006-02-13T10:14:43Z","receivedAt":"2006-02-13T10:14:43Z","isPatch":false,"sender":{"key":"ryan@michonline.com","avatar":null},"body":"On Mon, Feb 13, 2006 at 01:51:46AM -0800, Andrew Morton wrote:\n> \n> Assuming I find the bad commit, how do I extract it as a patch?\n> \n> I tried\n> \n> git-format-patch -o ~/a 386093ef9a6c88576d8b418bf1c8616d5e410a20 git-netdev-all\n> \n> and that chewed 10 minutes CPU time and produced no output, so I killed it.\n\nWell, assuming it's not a merge, you'll want something like this:\n\ngit format-patch -o ~/a 386093ef9a6c88576d8b418bf1c8616d5e410a20^1..386093ef9a6c88576d8b418bf1c8616d5e410a20\n\nFor essentially the same output, you can do a few other variations:\n\ngit whatchanged -p 386093ef9a6c88576d8b418bf1c8616d5e410a20^1..386093ef9a6c88576d8b418bf1c8616d5e410a20\ngit diff 386093ef9a6c88576d8b418bf1c8616d5e410a20^1..386093ef9a6c88576d8b418bf1c8616d5e410a20\n\nIf it's a merge that bisect terminates on, things get a bit trickier, as\nyou want to figure out what went wrong in the merge to cause it, so\nyou'll want to use either the syntax for specifying which merge parent\nto look at (which I forget at the moment) or, run:\n\tgit rev-list --parents --max-count=1 386093ef9a6c88576d8b418bf1c8616d5e410a20\nand look at columns 2+ individually.\n\nIn fact, if you want, you can re-do the merge, by creating some branches\nbased off of each parent, then pulling one into the other, and seeing\nwhat went wrong.\n\nHope that helps (if not, I apologize - I should've gone to bed a while\nago and it may have snuck through)\n\n-- \n\nRyan Anderson\n sometimes Pug Majere\n"},{"id":"16039","messageId":"20060213021917.742b2b10.akpm@osdl.org","threadId":"3320","inReplyTo":"7vbqxb1sho.fsf@assigned-by-dhcp.cox.net","subject":"Re: git-bisect problem","fromName":"Andrew Morton","fromEmail":"akpm@osdl.org","sentAt":"2006-02-13T10:19:17Z","receivedAt":"2006-02-13T10:19:17Z","isPatch":false,"sender":{"key":"akpm@osdl.org","avatar":null},"body":"Junio C Hamano wrote:\n>\n> Andrew Morton writes:\n> \n> >> As humans, we can tell that it is not very plausible that the\n> >> EXTRAVERSION change caused whatever breakage you are chasing,\n> >> but sorry, from your log, I think bisect is doing the right\n> >> thing.\n> >\n> > I don't think humans are well-suited to using git.\n> \n> I did not mean that ;-). Git is not as smart as humans.\n> \n> > My current theory is that I was bisecting Linus's tree all along.\n> \n> Sorry, I did not realize that was _not_ what you were doing.\n> Your log started by saying 2.6.16-rc1 is good but 2.6.16-rc2 was\n> not, so I just assumed your bug was between those two.\n> \n> If your suspect was merged between these two versions, then it\n> does not matter which branch you were _on_ when you started to\n> bisect. \n> \n> You mark points that are good and bad, and wander around in the\n> commit DAG, trying to narrow down the distance between known\n> good points and bad points while bisecting, and during that, you\n> are not really on _any_ branch.\n\nSo how am I supposed to find this bug in Jeff's tree?\n\nI do git-checkout -f git-netdev-all, then do the bisection and I come up\nwith junk.\n\n\n\nIt points at this:\n\ncommit a03b1950521466e007288a25c9fc7ac7f05a97e5\nMerge: 0b310f36d7d96e27f6941ec0f9b95e15142f1e78 c6f0d75a2defe8c7d8bf9f78de891cedc46b4b3e\nAuthor: Jeff Garzik \nDate: Tue Jan 31 11:52:21 2006 -0500\n\n Merge branch 'upstream-fixes'\n\n\n\ngit-bisect start\n# good: [d834a41c966c6a20368fadb59248740935e6fbae] ipw2200: do not sleep in ipw_request_direct_scan\ngit-bisect good d834a41c966c6a20368fadb59248740935e6fbae\n# bad: [b0afb58735e5dae05cb06ce6d0ca3073f390e9dc] Merge branch 'upstream'\ngit-bisect bad b0afb58735e5dae05cb06ce6d0ca3073f390e9dc\n# good: [0c19585b0d2f6817dd9af607650d3f6cae2fd8bc] uml: typo fixup\ngit-bisect good 0c19585b0d2f6817dd9af607650d3f6cae2fd8bc\n# good: [71baa1a599c04ab56ebf5fdb8d03abd0d601462f] [MIPS] Get rid of unnecessary prototypes. Fixes and optimizations for HZ > 100.\ngit-bisect good 71baa1a599c04ab56ebf5fdb8d03abd0d601462f\n# good: [d04e4e115bd9df2b748cb30abd610f3c0eb1e303] eeh_driver NULL noise removal\ngit-bisect good d04e4e115bd9df2b748cb30abd610f3c0eb1e303\n# good: [9908104935325bd6beba67d637b6f5396d47075c] [IPV6]: Address autoconfiguration does not work after device down/up cycle\ngit-bisect good 9908104935325bd6beba67d637b6f5396d47075c\n# good: [0b310f36d7d96e27f6941ec0f9b95e15142f1e78] Merge branch 'upstream' of git://git.kernel.org/pub/scm/linux/kernel/git/linville/wireless-2.6\ngit-bisect good 0b310f36d7d96e27f6941ec0f9b95e15142f1e78\n# bad: [70c07e02625ec46d0ffbfce1acef42d660803528] Merge branch 'viro'\ngit-bisect bad 70c07e02625ec46d0ffbfce1acef42d660803528\n# good: [2746b8623abce815aaae7afc946b1b39f8436f5a] Merge branch 'net.b0' of git://git.kernel.org/pub/scm/linux/kernel/git/viro/bird\ngit-bisect good 2746b8623abce815aaae7afc946b1b39f8436f5a\n# bad: [6bd0e10e53cc4824cd8cdaab8c370e53ab2e23c2] Merge branch 'sundance'\ngit-bisect bad 6bd0e10e53cc4824cd8cdaab8c370e53ab2e23c2\n# bad: [3c9b3a8575b4f2551e3b5b74ffa1c3559c6338eb] Merge branch 'master'\ngit-bisect bad 3c9b3a8575b4f2551e3b5b74ffa1c3559c6338eb\n# bad: [c0d3c0c0ce94d3db893577ae98e64414d92e49d8] [netdrvr] schedule eepro100 for removal\ngit-bisect bad c0d3c0c0ce94d3db893577ae98e64414d92e49d8\n# bad: [a03b1950521466e007288a25c9fc7ac7f05a97e5] Merge branch 'upstream-fixes'\ngit-bisect bad a03b1950521466e007288a25c9fc7ac7f05a97e5\n"},{"id":"16040","messageId":"20060213102225.24897.qmail@web31804.mail.mud.yahoo.com","threadId":"3320","inReplyTo":"20060213095859.GA17115@ferdyx.org","subject":"Re: git-bisect problem","fromName":"Luben Tuikov","fromEmail":"ltuikov@yahoo.com","sentAt":"2006-02-13T10:22:25Z","receivedAt":"2006-02-13T10:22:25Z","isPatch":false,"sender":{"key":"ltuikov@yahoo.com","avatar":null},"body":"--- \"Fernando J. Pereda\" wrote:\n\n> On Mon, Feb 13, 2006 at 01:51:46AM -0800, Andrew Morton wrote:\n> | Assuming I find the bad commit, how do I extract it as a patch?\n> | \n> | I tried\n> | \n> | git-format-patch -o ~/a 386093ef9a6c88576d8b418bf1c8616d5e410a20 git-netdev-all\n> | \n> | and that chewed 10 minutes CPU time and produced no output, so I killed it.\n> \n> This gives you the whole info about the commit, including a patch:\n> \n> git cat-file commit 386093ef9a6c88576d8b418bf1c8616d5e410a20\n\nI personally like\n\n git-diff-file\n"},{"id":"16041","messageId":"20060213102324.83478.qmail@web31809.mail.mud.yahoo.com","threadId":"3320","inReplyTo":"20060213095859.GA17115@ferdyx.org","subject":"Re: git-bisect problem","fromName":"Luben Tuikov","fromEmail":"ltuikov@yahoo.com","sentAt":"2006-02-13T10:23:24Z","receivedAt":"2006-02-13T10:23:24Z","isPatch":false,"sender":{"key":"ltuikov@yahoo.com","avatar":null},"body":"--- \"Fernando J. Pereda\" wrote:\n\n> On Mon, Feb 13, 2006 at 01:51:46AM -0800, Andrew Morton wrote:\n> | Assuming I find the bad commit, how do I extract it as a patch?\n> | \n> | I tried\n> | \n> | git-format-patch -o ~/a 386093ef9a6c88576d8b418bf1c8616d5e410a20 git-netdev-all\n> | \n> | and that chewed 10 minutes CPU time and produced no output, so I killed it.\n> \n> This gives you the whole info about the commit, including a patch:\n> \n> git cat-file commit 386093ef9a6c88576d8b418bf1c8616d5e410a20\n\nI meant to say:\n\n git-diff-tree --pretty -p \n\nLuben\n"},{"id":"16042","messageId":"20060213022527.3f888666.akpm@osdl.org","threadId":"3320","inReplyTo":"20060213101443.GD11053@mythryan2.michonline.com","subject":"Re: git-bisect problem","fromName":"Andrew Morton","fromEmail":"akpm@osdl.org","sentAt":"2006-02-13T10:25:27Z","receivedAt":"2006-02-13T10:25:27Z","isPatch":false,"sender":{"key":"akpm@osdl.org","avatar":null},"body":"Ryan Anderson wrote:\n>\n> On Mon, Feb 13, 2006 at 01:51:46AM -0800, Andrew Morton wrote:\n> > \n> > Assuming I find the bad commit, how do I extract it as a patch?\n> > \n> > I tried\n> > \n> > git-format-patch -o ~/a 386093ef9a6c88576d8b418bf1c8616d5e410a20 git-netdev-all\n> > \n> > and that chewed 10 minutes CPU time and produced no output, so I killed it.\n> \n> Well, assuming it's not a merge, you'll want something like this:\n> \n> git format-patch -o ~/a 386093ef9a6c88576d8b418bf1c8616d5e410a20^1..386093ef9a6c88576d8b418bf1c8616d5e410a20\n\nThat worked.\n\n> For essentially the same output, you can do a few other variations:\n> \n> git whatchanged -p 386093ef9a6c88576d8b418bf1c8616d5e410a20^1..386093ef9a6c88576d8b418bf1c8616d5e410a20\n> git diff 386093ef9a6c88576d8b418bf1c8616d5e410a20^1..386093ef9a6c88576d8b418bf1c8616d5e410a20\n> \n> If it's a merge that bisect terminates on, things get a bit trickier, as\n> you want to figure out what went wrong in the merge to cause it, so\n> you'll want to use either the syntax for specifying which merge parent\n> to look at (which I forget at the moment) or, run:\n> \tgit rev-list --parents --max-count=1 386093ef9a6c88576d8b418bf1c8616d5e410a20\n> and look at columns 2+ individually.\n\nIt did terminate on a merge. Thats over four hours gone and, frankly, I'm\nsick of it. I just want the darned diffs so I can do something useful.\n\n> In fact, if you want, you can re-do the merge, by creating some branches\n> based off of each parent, then pulling one into the other, and seeing\n> what went wrong.\n> \n> Hope that helps (if not, I apologize - I should've gone to bed a while\n> ago and it may have snuck through)\n\nIt does.\n\nI'm still not having much success geting a string of patches out of it.\n\ngit format-patch -o ~/a d834a41c966c6a20368fadb59248740935e6fbae..826eeb53a6f264842200d3311d69107d2eb25f5e\n\nHas chewed 5 minutes CPU so far and hasn't produced anything.\n\nHow do I get the IPW patches out of Jeff's tree, in order?\n\nI guess since I found a command which actually works, I can type that\n20-odd times.\n"},{"id":"16043","messageId":"20060213104036.67433.qmail@web31811.mail.mud.yahoo.com","threadId":"3320","inReplyTo":"20060213101443.GD11053@mythryan2.michonline.com","subject":"Re: git-bisect problem","fromName":"Luben Tuikov","fromEmail":"ltuikov@yahoo.com","sentAt":"2006-02-13T10:40:36Z","receivedAt":"2006-02-13T10:40:36Z","isPatch":false,"sender":{"key":"ltuikov@yahoo.com","avatar":null},"body":"Andrew,\n\nHere is the output:\n\n$ git-diff-tree --pretty -p 386093ef9a6c88576d8b418bf1c8616d5e410a20\ndiff-tree 386093ef9a6c88576d8b418bf1c8616d5e410a20 (from ce5f8d70ba6e3d7ffcaff86b2cf91a42c27f77af)\nAuthor: Alexey Dobriyan \nDate: Wed Feb 1 03:04:57 2006 -0800\n\n [PATCH] ipw2200: fix ->eeprom[EEPROM_VERSION] check\n \n priv->eeprom is a pointer.\n \n Signed-off-by: Alexey Dobriyan \n Acked-by: Yi Zhu \n Cc: James Ketrenos \n Signed-off-by: Andrew Morton \n Signed-off-by: Linus Torvalds \n\ndiff --git a/drivers/net/wireless/ipw2200.c b/drivers/net/wireless/ipw2200.c\nindex 916b24c..14beab4 100644\n--- a/drivers/net/wireless/ipw2200.c\n+++ b/drivers/net/wireless/ipw2200.c\n@@ -2456,7 +2456,7 @@ static void ipw_eeprom_init_sram(struct \n copy. Otherwise let the firmware know to perform the operation\n on it's own\n */\n- if ((priv->eeprom + EEPROM_VERSION) != 0) {\n+ if (priv->eeprom[EEPROM_VERSION] != 0) {\n IPW_DEBUG_INFO(\"Writing EEPROM data into SRAM\\n\");\n \n /* write the eeprom data to sram */\n\n Luben\n"},{"id":"16044","messageId":"20060213024456.6b68a1fa.akpm@osdl.org","threadId":"3320","inReplyTo":"20060213104036.67433.qmail@web31811.mail.mud.yahoo.com","subject":"Re: git-bisect problem","fromName":"Andrew Morton","fromEmail":"akpm@osdl.org","sentAt":"2006-02-13T10:44:56Z","receivedAt":"2006-02-13T10:44:56Z","isPatch":false,"sender":{"key":"akpm@osdl.org","avatar":null},"body":"Luben Tuikov wrote:\n>\n> Andrew,\n> \n> Here is the output:\n> \n> $ git-diff-tree --pretty -p 386093ef9a6c88576d8b418bf1c8616d5e410a20\n\nYes, that is decent. But for many patches, I'd end up having to call the\nfiles \"386093ef9a6c88576d8b418bf1c8616d5e410a20.patch\". git-format-patch\nchooses nice filenames. Slowly.\n\nAnyway, repeated applications of the one-diff git-format-patch (based on a\ngrep of the git-log output) got me the 69 patches which I want, so I can\nfind this bug now, thanks.\n"},{"id":"16045","messageId":"20060213122119.GE3065@always.joy.eth.net","threadId":"3320","inReplyTo":"20060213095859.GA17115@ferdyx.org","subject":"cat-file (was Re: git-bisect problem)","fromName":"Joshua N Pritikin","fromEmail":"jpritikin@pobox.com","sentAt":"2006-02-13T12:21:19Z","receivedAt":"2006-02-13T12:21:19Z","isPatch":false,"sender":{"key":"jpritikin@pobox.com","avatar":"https://gravatar.com/avatar/3f2561fdd7efac4e127dc65ac7e06f044069c115dcc94d0ac540f4126d47759d?d=mp&s=160"},"body":"On Mon, Feb 13, 2006 at 10:58:59AM +0100, Fernando J. Pereda wrote:\n> This gives you the whole info about the commit, including a patch:\n> \n> git cat-file commit 386093ef9a6c88576d8b418bf1c8616d5e410a20\n\nEh? Then why not call the command \"cat-object\" or simply \"cat\"?\n\n-- \nMake April 15 just another day, visit http://fairtax.org\n"},{"id":"16051","messageId":"Pine.LNX.4.64.0602130838010.3691@g5.osdl.org","threadId":"3320","inReplyTo":"20060213022527.3f888666.akpm@osdl.org","subject":"Re: git-bisect problem","fromName":"Linus Torvalds","fromEmail":"torvalds@osdl.org","sentAt":"2006-02-13T16:44:42Z","receivedAt":"2006-02-13T16:44:42Z","isPatch":false,"sender":{"key":"torvalds@linux-foundation.org","avatar":"https://avatars.githubusercontent.com/u/1024025?v=4"},"body":"\n\nOn Mon, 13 Feb 2006, Andrew Morton wrote:\n\n> Ryan Anderson wrote:\n> > \n> > git format-patch -o ~/a 386093ef9a6c88576d8b418bf1c8616d5e410a20^1..386093ef9a6c88576d8b418bf1c8616d5e410a20\n> \n> That worked.\n\nWell, really, it's much nicer these days to just say\n\n\tgit show 386093ef9\n\nand you're done.\n\nFor me, it gives a nice\n\n\tdiff-tree 386093ef9a6c88576d8b418bf1c8616d5e410a20 (from ce5f8d70ba6e3d7ffcaff86b2cf91a42c27f77af)\n\tAuthor: Alexey Dobriyan \n\tDate: Wed Feb 1 03:04:57 2006 -0800\n\t\n\t [PATCH] ipw2200: fix ->eeprom[EEPROM_VERSION] check\n\t \n\t priv->eeprom is a pointer.\n\t \n\t Signed-off-by: Alexey Dobriyan \n\t Acked-by: Yi Zhu \n\t Cc: James Ketrenos \n\t Signed-off-by: Andrew Morton \n\t Signed-off-by: Linus Torvalds \n\t\n\tdiff --git a/drivers/net/wireless/ipw2200.c b/drivers/net/wireless/ipw2200.c\n\tindex 916b24c..14beab4 100644\n\t--- a/drivers/net/wireless/ipw2200.c\n\t+++ b/drivers/net/wireless/ipw2200.c\n\t@@ -2456,7 +2456,7 @@ static void ipw_eeprom_init_sram(struct \n\t copy. Otherwise let the firmware know to perform the operation\n\t on it's own\n\t */\n\t- if ((priv->eeprom + EEPROM_VERSION) != 0) {\n\t+ if (priv->eeprom[EEPROM_VERSION] != 0) {\n\t IPW_DEBUG_INFO(\"Writing EEPROM data into SRAM\\n\");\n\t \n\t /* write the eeprom data to sram */\n\nwhich looks sane.\n\n> I'm still not having much success geting a string of patches out of it.\n> \n> git format-patch -o ~/a d834a41c966c6a20368fadb59248740935e6fbae..826eeb53a6f264842200d3311d69107d2eb25f5e\n\nwell, that's 1003 patches you're asking for. \n\nThat's almost certainly _not_ what you want.\n\nDo \"gitk ..args..\" to visually see what you're doing. Or, what I did:\n\n\tgit-rev-list d834a41c966c6a20368fadb59248740935e6fbae..826eeb53a6f264842200d3311d69107d2eb25f5e |\n\t\twc -l\n\nwhich is how I got the 1003.\n\nI'm pretty sure it wasn't what you meant to do.\n\n> How do I get the IPW patches out of Jeff's tree, in order?\n> \n> I guess since I found a command which actually works, I can type that\n> 20-odd times.\n\n\"git show\". Much simpler. HOWEVER. Doing that 20-odd times sounds insane. \nJust use gitk to see that you actually have the right starting and ending \npoints.\n\nVisualizing the history really is very important. If you had tried gitk, \nyou'd have immediately seen what you were doing, and that it wasn't what \nyou wanted.\n\nOnly after you're really comfortable with git should you do anything at \nall without looking at it visually first.\n\n(After you've done that a few months, you won't need it any more - your \nbrain will be able to visualize things on its own. gitk is just the \ntraining wheels).\n\n\t\t\tLinus\n"},{"id":"16067","messageId":"7v8xsezsni.fsf@assigned-by-dhcp.cox.net","threadId":"3320","inReplyTo":"20060213021917.742b2b10.akpm@osdl.org","subject":"Re: git-bisect problem","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2006-02-14T00:32:49Z","receivedAt":"2006-02-14T00:32:49Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Andrew Morton writes:\n\n> Junio C Hamano wrote:\n>>\n>> Andrew Morton writes:\n>> \n>> > My current theory is that I was bisecting Linus's tree all along.\n>> \n>> Sorry, I did not realize that was _not_ what you were doing.\n>> Your log started by saying 2.6.16-rc1 is good but 2.6.16-rc2 was\n>> not, so I just assumed your bug was between those two.\n>\n> So how am I supposed to find this bug in Jeff's tree?\n\nSorry, this question is what I do not quite understand.\n\nHere is my understanding of the situation.\n\n - Betweeen 2.6.16-rc1 and 2.6.16-rc2 a bug you are chasing was\n introduced. You know rc1 works fine but rc2 is bad.\n\n - You suspect that changes introduced by merging Jeff's tree\n at some point between -rc1 and -rc2 may be causing this.\n\nAm I totally misunderstanding the situation?\n\nBisecting, starting from -rc1 and -rc2 marked good and bad would\nfind the bug provided if the symptom is caused by a single bug\n(that is, before that commit things work but after that things\nstop working) that is in any commit that was not present in -rc1\nbut in -rc2. That includes what was merged from Jeff's tree, so\neven if you were \"bisecting Linus' tree all along\", if -rc1 was\ngood and -rc2 was bad, that would have found the bug in Jeff's\ntree (if it was what introduced the bug). As long as that was\nmerged between these two -- but otherwise breakage in -rc2 would\nnot have anything to do with Jeff's tree, so that is one reason\nI am confused by your emphasis on \"in Jeff's tree\" part.\n\n\n good bad\n -rc1 -rc2\n ---o---o---o---*---*---*---*---*---*\n \\ \\ / /\n \\ *---* /\n \\ / \n *---*---*---*---*\n Jeff's \n\nYour bisection that starts with good -rc1 and bad -rc2 would try\nto bisect commits that are not reachable from good ones (that\nis, parents before good ones are assumed to be good, since\nbisect is only good to look for a single regression), so at the\nbeginning, all '*' commits are suspects. bisection picks one of\nthem and after testing it, depending on it is good or bad, mark\nabout the half of the remaining graph \"unsuspected\". So even if\nyou start out with two commits on Linus' tree, you will wander\ninto Jeff's tree, if the suspect commit is in there. I am\nconfused by your emphasis on \"in Jeff's tree\" part.\n\nMaybe you are saying that you _know_ what broke was from Jeff's\ntree, and felt bisecting other parts of Linus' tree was\nwasteful?\n\nIf so, you can use gitk to visualize the graph, find the merge\nLinus' did to merge from Jeff (and I presume you already did so\nand that is why you are suspecting Jeff's tree). Mark that as\nbad, not -rc2. Also if you know the commit on Linus' tree\nbefore that merge was good (and I presume you already did so\nand that is why you are suspecting Jeff's tree), mark that as\ngood, not -rc1.\n\n -rc1 good bad -rc2\n ---o---o---o---o---o---o---*---o---o\n \\ \\ / /\n \\ o---o /\n \\ / \n *---*---*---*---*\n Jeff's \n\nThen your bisect will walk over commits on Jeff's tree.\n\nIs this helpful, or am I still completely useless?\n"},{"id":"16066","messageId":"7v3bimzsn2.fsf@assigned-by-dhcp.cox.net","threadId":"3320","inReplyTo":"20060213015146.26e6c09d.akpm@osdl.org","subject":"Re: git-bisect problem","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2006-02-14T00:33:05Z","receivedAt":"2006-02-14T00:33:05Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Andrew Morton writes:\n\n> git-format-patch -o ~/a 386093ef9a6c88576d8b418bf1c8616d5e410a20 git-netdev-all\n>\n> and that chewed 10 minutes CPU time and produced no output, so I killed it.\n\nA single commit is either:\n\n\tgit format-patch -o ~/a 386093^ 386093\n\tgit show 386093\n\nBut if you _did_ want to get everything that builds on top of\n386093 (and Linus counted 1000+ commits if I recall),\nformat-patch could be optimized. It currently does a lot more\nthan just format 1000+ commits, to handle case where \"his\" and\n\"mine\" are not linear history and may have the same change\nacquired by applying the same patch:\n\n 1---2---3 mine\n /\n ---4---5---6 his\n\nIn this picture, it does not just format 1 2 3. It first checks\n1 2 3 5 6, and if each of 1 2 3 introduces the same change as\neither 5 or 6 introduces to omit it from the output. If 2 and 5\nare the same change from 1 and 4 respectively, the final result\nhas 1 and 3. This is OK and useful for smaller branch, but\nclearly expensive for long branches.\n\nThis is omitted when the ancestry graph would look like this:\n\t\n 1---2---3 mine\n /\n ---4 his\n\nbut that would not have helped in this case anyway.\n\nMaybe we could have --no-omit-common flag or something to\ndisable this check.\n"},{"id":"16069","messageId":"20060213165620.11ec6051.akpm@osdl.org","threadId":"3320","inReplyTo":"7v8xsezsni.fsf@assigned-by-dhcp.cox.net","subject":"Re: git-bisect problem","fromName":"Andrew Morton","fromEmail":"akpm@osdl.org","sentAt":"2006-02-14T00:56:20Z","receivedAt":"2006-02-14T00:56:20Z","isPatch":false,"sender":{"key":"akpm@osdl.org","avatar":null},"body":"Junio C Hamano wrote:\n>\n> Sorry, this question is what I do not quite understand.\n> \n> Here is my understanding of the situation.\n> \n> - Betweeen 2.6.16-rc1 and 2.6.16-rc2 a bug you are chasing was\n> introduced. You know rc1 works fine but rc2 is bad.\n> \n> - You suspect that changes introduced by merging Jeff's tree\n> at some point between -rc1 and -rc2 may be causing this.\n> \n> Am I totally misunderstanding the situation?\n\nyup ;)\n\nThe bug is in Jeff's tree only\n(git+ssh://master.kernel.org/pub/scm/linux/kernel/git/jgarzik/netdev-2.6.git#ALL)\nso I wanted to perform the bisection on the git-netdev-all branch.\n\nSo I did a `git log git-netdev-all' and looked at where the ipw2200 changes\nwere and then decided that the 2.6.16-rc1 and 2.6.16-rc2 commits straddled\nthose changes nicely, so I chose those as the bisection starting points.\n"},{"id":"16070","messageId":"Pine.LNX.4.64.0602131706460.3691@g5.osdl.org","threadId":"3320","inReplyTo":"20060213165620.11ec6051.akpm@osdl.org","subject":"Re: git-bisect problem","fromName":"Linus Torvalds","fromEmail":"torvalds@osdl.org","sentAt":"2006-02-14T01:14:25Z","receivedAt":"2006-02-14T01:14:25Z","isPatch":false,"sender":{"key":"torvalds@linux-foundation.org","avatar":"https://avatars.githubusercontent.com/u/1024025?v=4"},"body":"\n\nOn Mon, 13 Feb 2006, Andrew Morton wrote:\n> \n> The bug is in Jeff's tree only\n> (git+ssh://master.kernel.org/pub/scm/linux/kernel/git/jgarzik/netdev-2.6.git#ALL)\n> so I wanted to perform the bisection on the git-netdev-all branch.\n\nActually, what you should do, is not play any games at all, but just tell \n\"git bisect\" what the problem is. It will do the right thing.\n\nSo in this case, what you do is _literally_ to\n\n\t# fetch Jeff's tree (you obviously had this already, but I just \n\t# want to point it out as a \"name that branch\" thing)\n\tgit fetch netdev-all\n\n\t# we know that that tree is broken\n\tgit bisect start\n\tgit bisect bad netdev-all\n\n\t# We know that Linus' top-of-tree doesn't have the bug\n\tgit bisect good origin\n\nand off you go. It absolutely magically does the right thing, and will \nbisect stuff that is only in the netdev branch and not in my tree. No \nguessing necessary, no need to try to figure out what the differences are. \ngit will do it all for you.\n\nAnd notice how it will work perfectly well, even if the two points you \nhave tested AREN'T EVEN DIRECTLY RELATED! The \"good\" and \"bad\" points do \nnot have to have any direct relationship other than a common parent \n_somewhere_. \"git bisect\" really is that good.\n\n(The above is obviously assuming that \"origin\" is set to my tree, \nself-aggrandizing bastard that I am, and that you've set up a \n.git/remotes/netdev-all file pointing to Jeff's tree - your setup may vary \nfrom this, so you'd have to change the lines to match)\n\n\t\t\tLinus\n"},{"id":"16071","messageId":"20060214011512.GB31278@pasky.or.cz","threadId":"3320","inReplyTo":"20060213165620.11ec6051.akpm@osdl.org","subject":"Re: git-bisect problem","fromName":"Petr Baudis","fromEmail":"pasky@suse.cz","sentAt":"2006-02-14T01:15:12Z","receivedAt":"2006-02-14T01:15:12Z","isPatch":false,"sender":{"key":"pasky@ucw.cz","avatar":"https://avatars.githubusercontent.com/u/18439?v=4"},"body":"Dear diary, on Tue, Feb 14, 2006 at 01:56:20AM CET, I got a letter\nwhere Andrew Morton said that...\n> Junio C Hamano wrote:\n> >\n> > Sorry, this question is what I do not quite understand.\n> > \n> > Here is my understanding of the situation.\n> > \n> > - Betweeen 2.6.16-rc1 and 2.6.16-rc2 a bug you are chasing was\n> > introduced. You know rc1 works fine but rc2 is bad.\n> > \n> > - You suspect that changes introduced by merging Jeff's tree\n> > at some point between -rc1 and -rc2 may be causing this.\n> > \n> > Am I totally misunderstanding the situation?\n> \n> yup ;)\n> \n> The bug is in Jeff's tree only\n> (git+ssh://master.kernel.org/pub/scm/linux/kernel/git/jgarzik/netdev-2.6.git#ALL)\n> so I wanted to perform the bisection on the git-netdev-all branch.\n> \n> So I did a `git log git-netdev-all' and looked at where the ipw2200 changes\n> were and then decided that the 2.6.16-rc1 and 2.6.16-rc2 commits straddled\n> those changes nicely, so I chose those as the bisection starting points.\n\nBut aren't those commits on the Linus' \"branch\", not containing any\ncommits specific to git-netdev-all?\n\nI imagine the situation is like:\n\n* -- 2.6.16-rc1 -- * -- * -- 2.6.16-rc2 -- * - - (linus)\n \\ \\ \\\n* -- * -- * -- * -- * -- * -- * -- * -- * -- M - - (git-netdev-all)\n\nThen, if you bisect between -rc2 and -rc1, you will never actually get\nto the git-netdev-all branch, since there are no such commits inbetween\n-rc2 and -rc1. Even if you consider this:\n\n* -- 2.6.16-rc1 -- * -- * -- 2.6.16-rc2 -- * - - (linus)\n \\ / \\ \\\n* -- X -- Y -- Z -- A -- * -- * -- * -- * -- M - - (git-netdev-all)\n\ngit-bisect will consider the X, Y, Z commits (since they are part of the\nancestry between -rc and -rc2), but not commits from A on - it can't\nreach them topologically if it considers only commits between -rc1 and\n-rc2:\n\n* -- 2.6.16-rc1 -- * -- * -- 2.6.16-rc2\n \\ /\n - X -- Y -- Z\n\nNow, perhaps what you meant is that \"when -rc2 got merged to netdev-all,\nthings were already broken\". In this case, what you want to do is to use\nthe commit M as the bisect bad point. Then, bisect will walk this\nsubgraph:\n\n* -- 2.6.16-rc1 -- * -- * -- 2.6.16-rc2\n \\ / \\ \\\n - X -- Y -- Z -- A -- * -- * -- * -- * -- M\n\nI agree that this can be kind of confusing; I'm not sure how to avoid\nthis. Perhaps git-bisect should warn if when bisecting between Q and P,\nthere exists a path between HEAD and P avoiding Q...?\n\n-- \n\t\t\t\tPetr \"Pasky\" Baudis\nStuff: http://pasky.or.cz/\nOf the 3 great composers Mozart tells us what it's like to be human,\nBeethoven tells us what it's like to be Beethoven and Bach tells us\nwhat it's like to be the universe. -- Douglas Adams\n"},{"id":"16072","messageId":"20060214012755.GC31278@pasky.or.cz","threadId":"3320","inReplyTo":"20060214011512.GB31278@pasky.or.cz","subject":"Re: git-bisect problem","fromName":"Petr Baudis","fromEmail":"pasky@suse.cz","sentAt":"2006-02-14T01:27:55Z","receivedAt":"2006-02-14T01:27:55Z","isPatch":false,"sender":{"key":"pasky@ucw.cz","avatar":"https://avatars.githubusercontent.com/u/18439?v=4"},"body":"Dear diary, on Tue, Feb 14, 2006 at 02:15:12AM CET, I got a letter\nwhere Petr Baudis said that...\n> Dear diary, on Tue, Feb 14, 2006 at 01:56:20AM CET, I got a letter\n> where Andrew Morton said that...\n> > Junio C Hamano wrote:\n> > >\n> > > Sorry, this question is what I do not quite understand.\n> > > \n> > > Here is my understanding of the situation.\n> > > \n> > > - Betweeen 2.6.16-rc1 and 2.6.16-rc2 a bug you are chasing was\n> > > introduced. You know rc1 works fine but rc2 is bad.\n> > > \n> > > - You suspect that changes introduced by merging Jeff's tree\n> > > at some point between -rc1 and -rc2 may be causing this.\n> > > \n> > > Am I totally misunderstanding the situation?\n> > \n> > yup ;)\n> > \n> > The bug is in Jeff's tree only\n> > (git+ssh://master.kernel.org/pub/scm/linux/kernel/git/jgarzik/netdev-2.6.git#ALL)\n> > so I wanted to perform the bisection on the git-netdev-all branch.\n> > \n> > So I did a `git log git-netdev-all' and looked at where the ipw2200 changes\n> > were and then decided that the 2.6.16-rc1 and 2.6.16-rc2 commits straddled\n> > those changes nicely, so I chose those as the bisection starting points.\n> \n> But aren't those commits on the Linus' \"branch\", not containing any\n> commits specific to git-netdev-all?\n> \n> I imagine the situation is like:\n> \n> * -- 2.6.16-rc1 -- * -- * -- 2.6.16-rc2 -- * - - (linus)\n> \\ \\ \\\n> * -- * -- * -- * -- * -- * -- * -- * -- * -- M - - (git-netdev-all)\n> \n> Then, if you bisect between -rc2 and -rc1, you will never actually get\n> to the git-netdev-all branch, since there are no such commits inbetween\n> -rc2 and -rc1. Even if you consider this:\n> \n> * -- 2.6.16-rc1 -- * -- * -- 2.6.16-rc2 -- * - - (linus)\n> \\ / \\ \\\n> * -- X -- Y -- Z -- A -- * -- * -- * -- * -- M - - (git-netdev-all)\n> \n> git-bisect will consider the X, Y, Z commits (since they are part of the\n> ancestry between -rc and -rc2), but not commits from A on - it can't\n> reach them topologically if it considers only commits between -rc1 and\n> -rc2:\n> \n> * -- 2.6.16-rc1 -- * -- * -- 2.6.16-rc2\n> \\ /\n> - X -- Y -- Z\n\nI got this one (and consequently, the following one) wrong - obviously,\nit should read as\n\n 2.6.16-rc1 -- * -- * -- 2.6.16-rc2\n /\n X -- Y -- Z\n\nsince the \"asterisk\" commit is already behind -rc1.\n\n\nPedagogical excursion:\n\nAll those commit intervals are really set differences - if you have\ncommit A and commit B,\n\n\t[A,B] = B \\cup (ancestry(B) \\ ancestry(A))\n\nor if you don't like math, color B and all its ancestors blue in\nyour head, and then color all the A ancestors black. The commits\nthat stay blue are in the [A,B] interval.\n\n-- \n\t\t\t\tPetr \"Pasky\" Baudis\nStuff: http://pasky.or.cz/\nOf the 3 great composers Mozart tells us what it's like to be human,\nBeethoven tells us what it's like to be Beethoven and Bach tells us\nwhat it's like to be the universe. -- Douglas Adams\n"},{"id":"16074","messageId":"7v8xseyae8.fsf@assigned-by-dhcp.cox.net","threadId":"3320","inReplyTo":"20060213165620.11ec6051.akpm@osdl.org","subject":"Re: git-bisect problem","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2006-02-14T01:52:31Z","receivedAt":"2006-02-14T01:52:31Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Andrew Morton writes:\n\n> The bug is in Jeff's tree only\n> (git+ssh://master.kernel.org/pub/scm/linux/kernel/git/jgarzik/netdev-2.6.git#ALL)\n> so I wanted to perform the bisection on the git-netdev-all branch.\n>\n> So I did a `git log git-netdev-all' and looked at where the ipw2200 changes\n> were and then decided that the 2.6.16-rc1 and 2.6.16-rc2 commits straddled\n> those changes nicely, so I chose those as the bisection starting points.\n\nAh. Jeff merges from Linus and that causes things on Linus tree\nto appear in his tree. So you saw -rc1 and -rc2 in the output,\nbut neither of them may contain the problematic change, and are\nnot good/bad pair at all. They are probably both good ones.\n\ngit log output is chronological and there is no guarantee that\nthe ordering has much to do with the actual ordering of commits,\nespecially when merges are involved. In fact, \"Jeff's tree\nonly\" suggests to me that 2.6.16-rc2 has not merged those\nchanges, but you thought (arguably rightly so) rc1 and rc2\nstraddled them.\n\n\n -rc1 -rc2\n ---o---o---o---o---o---o---o---o---o---o---o---o--- Linus\n \\ \n \\ \n ---o---o---o---*---o---o---o---*---o---o---o---o--- Jeff\n <- ipw2200 ->\n\nSo you would want to perhaps pick two commits like the above *\nand bisect. If the one marked as bad on the Linus tree\ninitially (-rc2) is not bad and does not reach the allegedly bad\ncommit on Jeff's line, there is no way for bisect to find it.\n\nIf you are suspecting ipw2200, 2f633db and 747af1e might be a\npair of good anchor points to start bisecting.\n\nThe way I came up with these two; I should be using gitk for\nthis kind of thing, but I do not work in X during daytime, so I\nam guessing these from:\n \n $ git rev-list --pretty=oneline linus..garzik/netdev |\n grep -C4 -i ipw2200 | less\n\nThis gets the list of commits that are on Jeff's tree but not in\nLinus' in reverse chrono order, and grabs ones with ipw2200 in\ntheir titles. It shows that 2f633db is (close to) the latest\nthat touches ipw2200, and 747af1e is (close to) the reasonably\nold that touches ipw2200. As a review of these two points, I\ndid this:\n\n\t$ git log 747af1e..2f633db\n\nHope it helps this time...\n"}]}