Mail Archives: cygwin/2012/06/08/12:46:19
On 6/8/2012 11:33 AM, Achim Gratz wrote:
> Ken Brown writes:
>> As I said earlier, I don't understand very well how git branches work,
>> but I *think* this means we have to look in the 2-32 branch, prior to
>> the 2.31.0 tag, to find the problematic commit. I've checked out the
>> 2-32 branch, and I guess the next step is to find a problem-free
>> revision of that branch, and then bisect between it and the 2.31.0
>> tag. I'm in the process of reading the git documentation to figure out
>> how to do that, but I wouldn't object if someone would save me some
>> time by giving me the appropriate git commands.
>
> I've had a quick look at how the GNOME folks use their release branches:
> they are tagged in master and then only some version bumping and a few
> quickfixes. There are no odd numbered releases, so I assume they start
> the disruptive changes right after a release, tag the unstable version
> in master with an odd number and then work out the kinks until the new
> release is done.
>
> So, you can indeed start on the 2.32 branch and then bisect down to the
> 2.30 tag. Don't bother with the run-up between 2.31 and 2.32, just
> bisect it whole, the bisect sequence will be just one build longer if at
> all.
>
> git checkout glib-2-32
> git bisect start bad
> git bisect good 2.30.3
>
> If any of the intermediate versions doesn't build, say
>
> git bisect skip
>
> with the offending commit still checked out.
Thanks, Achim. That helps a lot. The only thing I might have to change
is the starting point for the bisection, since the tag 2.30.3 represents
a fairly recent commit. But I think starting with 2.30.1 should work.
I'll give it a try.
Ken
--
Problem reports: http://cygwin.com/problems.html
FAQ: http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
- Raw text -