threads / discuss / 43605

Using git-bisect to find more than one breakage

Subject: Using git-bisect to find more than one breakage

## tl;dr

3 messages between Dec 12, 2006 and Dec 13, 2006.

replies: 2people: 2as markdown or json

n0dalus· Dec 12, 2006, 04:34 UTC · lore

Hi,

I am trying to find commits in the 2.6.18 linux tree that cause/trigger problems for a program I use. I found the first commit by using git-bisect. However, somewhere between that commit and master there is at least one more commit that breaks things. I'm sure there must be a way to find this, but the method I'm using doesn't seem to work (I'm new to git).

This is what I tried to do:
- Make a branch ("working") at the bad commit
- Commit a patch to undo the bug-causing change from that commit
- Make a copy of the master branch
- git-rebase working
- (Then if that worked, use git-bisect to find the next breakage)

I expected git-rebase to just apply all the commits from the master onto my working branch, possibly stopping in the case of a conflict to the file I patched. Instead, it produces large conflicts with unrelated files, on the very first commit it tries to apply. I even get the conflicts if the commit I make before using git-rebase changes no files at all (just adding an empty file 'test').

Is there something wrong with my method here? Is there another way to do this?

I am thinking for now I will just use git-bisect between the bad commit and master, and apply my changes to every bisection.

Any help greatly appreciated,

J. Bruce Fields· Dec 13, 2006, 14:34 UTC · re: n0dalus · lore

Re: Using git-bisect to find more than one breakage

On Tue, Dec 12, 2006 at 03:04:29PM +1030, n0dalus wrote:

Show 19 quoted lines

> This is what I tried to do:
> - Make a branch ("working") at the bad commit
> - Commit a patch to undo the bug-causing change from that commit
> - Make a copy of the master branch
> - git-rebase working
> - (Then if that worked, use git-bisect to find the next breakage)
> 
> I expected git-rebase to just apply all the commits from the master
> onto my working branch, possibly stopping in the case of a conflict to
> the file I patched. Instead, it produces large conflicts with
> unrelated files, on the very first commit it tries to apply. I even
> get the conflicts if the commit I make before using git-rebase changes
> no files at all (just adding an empty file 'test').
> 
> Is there something wrong with my method here? Is there another way to do 
> this?
> 
> I am thinking for now I will just use git-bisect between the bad
> commit and master, and apply my changes to every bisection.

Yes, that's the way to do it.

The git-rebase command is intended for rebasing small pieces of purely linear history; I don't believe it will work well (at all?) to rebase a large chunk of kernel history.

n0dalus· Dec 13, 2006, 15:06 UTC · re: J. Bruce Fields · lore

Re: Using git-bisect to find more than one breakage

On 12/14/06, J. Bruce Fields <bfields@fieldses.org> wrote:

Show 11 quoted lines

> On Tue, Dec 12, 2006 at 03:04:29PM +1030, n0dalus wrote:
> >
> > I am thinking for now I will just use git-bisect between the bad
> > commit and master, and apply my changes to every bisection.
>
> Yes, that's the way to do it.
>
> The git-rebase command is intended for rebasing small pieces of purely
> linear history; I don't believe it will work well (at all?) to rebase a
> large chunk of kernel history.
>

Yeah, I figured it couldn't deal with all the merges and stuff.

It'd be nice if the man page for git-rebase warned about it's inability to handle lots of complex merges. Or if the git-bisect man page mentioned that the easiest way to find more than one problem is to find and fix the first, then apply that fix to every bisection between that first problem and a known bad version.

Thanks though, now I can stop worrying about why the rebase wasn't working and concentrate on finding the bugs.