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,
On Tue, Dec 12, 2006 at 03:04:29PM +1030, n0dalus wrote:
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.
On 12/14/06, J. Bruce Fields [off-list ref] wrote:
On Tue, Dec 12, 2006 at 03:04:29PM +1030, n0dalus wrote:
quoted
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.