* Bisecting through the middle of a big merge?
@ 2012-01-28 0:03 walt
2012-01-28 8:55 ` Andreas Schwab
0 siblings, 1 reply; 5+ messages in thread
From: walt @ 2012-01-28 0:03 UTC (permalink / raw)
To: git
My problem is that I lack a good mental model of what git does
when it commits a big merge, and so I get lost when I try to
bisect back through a merge. (I'm a tester, not a developer.)
This specific recent example is causing me problems:
Merge: b3c9dd1 85a0f7b
Author: Linus Torvalds
Date: Sun Jan 15 12:48:41 2012 -0800
Merge branch 'for-3.3/drivers' of git://git.kernel.dk/linux-block
There are many individual commits from Tejun Heo et al included
in that one big commit from Linus. Unfortunately for me, some of
those commits cause other problems that I'm not trying to bisect;
other problems that evidently get fixed by other commits in the
same big merge.
So I do 'git bisect skip' six or eight times until the 'false' bug
goes away, and that leaves me at the end of the bisect without finding
the individual commit that's causing my 'real' bug.
How do you experts handle this kind of problem?
Thanks for any clues.
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: Bisecting through the middle of a big merge?
2012-01-28 0:03 Bisecting through the middle of a big merge? walt
@ 2012-01-28 8:55 ` Andreas Schwab
2012-01-28 18:15 ` walt
0 siblings, 1 reply; 5+ messages in thread
From: Andreas Schwab @ 2012-01-28 8:55 UTC (permalink / raw)
To: walt; +Cc: git
walt <w41ter@gmail.com> writes:
> There are many individual commits from Tejun Heo et al included
> in that one big commit from Linus. Unfortunately for me, some of
> those commits cause other problems that I'm not trying to bisect;
> other problems that evidently get fixed by other commits in the
> same big merge.
>
> So I do 'git bisect skip' six or eight times until the 'false' bug
> goes away, and that leaves me at the end of the bisect without finding
> the individual commit that's causing my 'real' bug.
>
> How do you experts handle this kind of problem?
If you can identify the commit that fixes the unrelated problem you can
try to cherry-pick it during the bisect.
Andreas.
--
Andreas Schwab, schwab@linux-m68k.org
GPG Key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5
"And now for something completely different."
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: Bisecting through the middle of a big merge?
2012-01-28 8:55 ` Andreas Schwab
@ 2012-01-28 18:15 ` walt
2012-01-28 19:47 ` Andreas Schwab
0 siblings, 1 reply; 5+ messages in thread
From: walt @ 2012-01-28 18:15 UTC (permalink / raw)
To: git
On 01/28/2012 12:55 AM, Andreas Schwab wrote:
> walt <w41ter@gmail.com> writes:
>
>> There are many individual commits from Tejun Heo et al included
>> in that one big commit from Linus. Unfortunately for me, some of
>> those commits cause other problems that I'm not trying to bisect;
>> other problems that evidently get fixed by other commits in the
>> same big merge.
>>
>> So I do 'git bisect skip' six or eight times until the 'false' bug
>> goes away, and that leaves me at the end of the bisect without finding
>> the individual commit that's causing my 'real' bug.
>>
>> How do you experts handle this kind of problem?
>
> If you can identify the commit that fixes the unrelated problem you can
> try to cherry-pick it during the bisect.
Thanks Andreas. With an eye to doing that, is there an easy way to
get a list of all the commits included in Linus's merge? (I mean a
more accurate list than Linus casually mentions in his commit message.)
Trying to build that mental model I mentioned: All the commits from
Tejun Heo are dated mid-December but Linus didn't commit them until
mid-January. When I'm bisecting through that merge, git builds the
kernels with names like vmlinuz-3.2.0-rc5-foo, i.e. names a month
older than Linus's current kernel version. Where does git get those
older names during the bisect? And does my working tree exclude all
of Linus's commits made later than 3.2.0-rc5-foo?
Many thanks.
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: Bisecting through the middle of a big merge?
2012-01-28 18:15 ` walt
@ 2012-01-28 19:47 ` Andreas Schwab
2012-01-28 22:18 ` walt
0 siblings, 1 reply; 5+ messages in thread
From: Andreas Schwab @ 2012-01-28 19:47 UTC (permalink / raw)
To: walt; +Cc: git
walt <w41ter@gmail.com> writes:
> With an eye to doing that, is there an easy way to get a list of all
> the commits included in Linus's merge?
$ git log merge-commit^..merge-commit
Andreas.
--
Andreas Schwab, schwab@linux-m68k.org
GPG Key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5
"And now for something completely different."
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: Bisecting through the middle of a big merge?
2012-01-28 19:47 ` Andreas Schwab
@ 2012-01-28 22:18 ` walt
0 siblings, 0 replies; 5+ messages in thread
From: walt @ 2012-01-28 22:18 UTC (permalink / raw)
To: git
On 01/28/2012 11:47 AM, Andreas Schwab wrote:
> walt <w41ter@gmail.com> writes:
>
>> With an eye to doing that, is there an easy way to get a list of all
>> the commits included in Linus's merge?
>
> $ git log merge-commit^..merge-commit
Amazing. And obvious now that you've already told me the answer.
I'm not thinking like a developer yet, but I'm working on it :)
^ permalink raw reply [flat|nested] 5+ messages in thread
end of thread, other threads:[~2012-01-28 22:18 UTC | newest]
Thread overview: 5+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2012-01-28 0:03 Bisecting through the middle of a big merge? walt
2012-01-28 8:55 ` Andreas Schwab
2012-01-28 18:15 ` walt
2012-01-28 19:47 ` Andreas Schwab
2012-01-28 22:18 ` walt
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).