X-Recipient: archive-cygwin AT delorie DOT com
X-SWARE-Spam-Status: No, hits=-2.0 required=5.0	tests=AWL,BAYES_00,KHOP_THREADED,SPF_NEUTRAL,T_RP_MATCHES_RCVD
X-Spam-Check-By: sourceware.org
Message-ID: <4FD22C39.6070107@cornell.edu>
Date: Fri, 08 Jun 2012 12:45:45 -0400
From: Ken Brown <kbrown AT cornell DOT edu>
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:12.0) Gecko/20120428 Thunderbird/12.0.1
MIME-Version: 1.0
To: cygwin AT cygwin DOT com
Subject: Re: Performance problems with emacs-X11 in current cygwin
References: <4FC7D9E6 DOT 5050609 AT alice DOT it> <4FCA1FF0 DOT 8090703 AT alice DOT it>	<4FCA2CA9 DOT 7080704 AT cornell DOT edu> <4FCA634D DOT 1080206 AT cornell DOT edu>	<4FCB2991 DOT 3010701 AT users DOT sourceforge DOT net>	<4FCB5438 DOT 7080903 AT cornell DOT edu> <4FCB9872 DOT 5010506 AT cornell DOT edu>	<loom DOT 20120606T123651-460 AT post DOT gmane DOT org>	<4FD1F709 DOT 4050107 AT cornell DOT edu> <87k3zhbyyk DOT fsf AT Rainer DOT invalid>
In-Reply-To: <87k3zhbyyk.fsf@Rainer.invalid>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-PMX-CORNELL-SPAM-CHECKED: Pawpaw
X-Original-Sender: kbrown AT cornell DOT edu - Fri Jun  8 12:45:52 2012
X-PMX-CORNELL-REASON: CU_White_List_Override
X-IsSubscribed: yes
Mailing-List: contact cygwin-help AT cygwin DOT com; run by ezmlm
List-Id: <cygwin.cygwin.com>
List-Subscribe: <mailto:cygwin-subscribe AT cygwin DOT com>
List-Archive: <http://sourceware.org/ml/cygwin/>
List-Post: <mailto:cygwin AT cygwin DOT com>
List-Help: <mailto:cygwin-help AT cygwin DOT com>, <http://sourceware.org/ml/#faqs>
Sender: cygwin-owner AT cygwin DOT com
Mail-Followup-To: cygwin AT cygwin DOT com
Delivered-To: mailing list cygwin AT cygwin DOT com

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