{"thread":{"id":"43605","subject":"Using git-bisect to find more than one breakage","startedAt":"2006-12-12T04:34:29Z","lastAt":"2006-12-13T15:06:36Z","messageCount":3,"participants":["n0dalus","J. Bruce Fields"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"295892","messageId":"6280325c0612112034x373c8022q909ca192a866cfcf@mail.gmail.com","threadId":"43605","inReplyTo":null,"subject":"Using git-bisect to find more than one breakage","fromName":"n0dalus","fromEmail":"n0dalus+redhat@gmail.com","sentAt":"2006-12-12T04:34:29Z","receivedAt":"2006-12-12T04:34:29Z","isPatch":false,"sender":{"key":"n0dalus+redhat@gmail.com","avatar":null},"body":"Hi,\n\nI am trying to find commits in the 2.6.18 linux tree that\ncause/trigger problems for a program I use. I found the first commit\nby using git-bisect. However, somewhere between that commit and master\nthere is at least one more commit that breaks things. I'm sure there\nmust be a way to find this, but the method I'm using doesn't seem to\nwork (I'm new to git).\n\nThis is what I tried to do:\n- Make a branch (\"working\") at the bad commit\n- Commit a patch to undo the bug-causing change from that commit\n- Make a copy of the master branch\n- git-rebase working\n- (Then if that worked, use git-bisect to find the next breakage)\n\nI expected git-rebase to just apply all the commits from the master\nonto my working branch, possibly stopping in the case of a conflict to\nthe file I patched. Instead, it produces large conflicts with\nunrelated files, on the very first commit it tries to apply. I even\nget the conflicts if the commit I make before using git-rebase changes\nno files at all (just adding an empty file 'test').\n\nIs there something wrong with my method here? Is there another way to do this?\n\nI am thinking for now I will just use git-bisect between the bad\ncommit and master, and apply my changes to every bisection.\n\nAny help greatly appreciated,\n"},{"id":"296423","messageId":"20061213143404.GA24132@fieldses.org","threadId":"43605","inReplyTo":"6280325c0612112034x373c8022q909ca192a866cfcf@mail.gmail.com","subject":"Re: Using git-bisect to find more than one breakage","fromName":"J. Bruce Fields","fromEmail":"bfields@fieldses.org","sentAt":"2006-12-13T14:34:04Z","receivedAt":"2006-12-13T14:34:04Z","isPatch":false,"sender":{"key":"bfields@citi.umich.edu","avatar":null},"body":"On Tue, Dec 12, 2006 at 03:04:29PM +1030, n0dalus wrote:\n> This is what I tried to do:\n> - Make a branch (\"working\") at the bad commit\n> - Commit a patch to undo the bug-causing change from that commit\n> - Make a copy of the master branch\n> - git-rebase working\n> - (Then if that worked, use git-bisect to find the next breakage)\n> \n> I expected git-rebase to just apply all the commits from the master\n> onto my working branch, possibly stopping in the case of a conflict to\n> the file I patched. Instead, it produces large conflicts with\n> unrelated files, on the very first commit it tries to apply. I even\n> get the conflicts if the commit I make before using git-rebase changes\n> no files at all (just adding an empty file 'test').\n> \n> Is there something wrong with my method here? Is there another way to do \n> this?\n> \n> I am thinking for now I will just use git-bisect between the bad\n> commit and master, and apply my changes to every bisection.\n\nYes, that's the way to do it.\n\nThe git-rebase command is intended for rebasing small pieces of purely\nlinear history; I don't believe it will work well (at all?) to rebase a\nlarge chunk of kernel history.\n\n"},{"id":"298347","messageId":"6280325c0612130706keb86890n1395ec765a140d60@mail.gmail.com","threadId":"43605","inReplyTo":"20061213143404.GA24132@fieldses.org","subject":"Re: Using git-bisect to find more than one breakage","fromName":"n0dalus","fromEmail":"n0dalus+redhat@gmail.com","sentAt":"2006-12-13T15:06:36Z","receivedAt":"2006-12-13T15:06:36Z","isPatch":false,"sender":{"key":"n0dalus+redhat@gmail.com","avatar":null},"body":"On 12/14/06, J. Bruce Fields <bfields@fieldses.org> wrote:\n> On Tue, Dec 12, 2006 at 03:04:29PM +1030, n0dalus wrote:\n> >\n> > I am thinking for now I will just use git-bisect between the bad\n> > commit and master, and apply my changes to every bisection.\n>\n> Yes, that's the way to do it.\n>\n> The git-rebase command is intended for rebasing small pieces of purely\n> linear history; I don't believe it will work well (at all?) to rebase a\n> large chunk of kernel history.\n>\n\nYeah, I figured it couldn't deal with all the merges and stuff.\n\nIt'd be nice if the man page for git-rebase warned about it's\ninability to handle lots of complex merges. Or if the git-bisect man\npage mentioned that the easiest way to find more than one problem is\nto find and fix the first, then apply that fix to every bisection\nbetween that first problem and a known bad version.\n\nThanks though, now I can stop worrying about why the rebase wasn't\nworking and concentrate on finding the bugs.\n\n"}]}