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. HTH, Achim. -- +<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+ Waldorf MIDI Implementation & additional documentation: http://Synth.Stromeko.net/Downloads.html#WaldorfDocs -- 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
