From: Ken Brown <kbrown@cornell.edu>
To: cygwin@cygwin.com
Subject: Re: Performance problems with emacs-X11 in current cygwin
Date: Fri, 08 Jun 2012 16:46:00 -0000 [thread overview]
Message-ID: <4FD22C39.6070107@cornell.edu> (raw)
In-Reply-To: <87k3zhbyyk.fsf@Rainer.invalid>
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
next prev parent reply other threads:[~2012-06-08 16:46 UTC|newest]
Thread overview: 47+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-05-31 21:02 Angelo Graziosi
2012-06-01 11:01 ` Performance problems with emacs-X11 in current cygwin (attn: glib and gvim maintainer) Ken Brown
2012-06-01 11:21 ` atelp
2012-06-01 11:57 ` Ken Brown
2012-06-01 16:23 ` Stephen L
2012-06-01 18:39 ` Ken Brown
2012-06-01 19:10 ` K Stahl
2012-06-02 14:15 ` Performance problems with emacs-X11 in current cygwin Angelo Graziosi
2012-06-02 15:09 ` Ken Brown
2012-06-02 19:03 ` Ken Brown
2012-06-03 9:08 ` Yaakov (Cygwin/X)
2012-06-03 12:11 ` Ken Brown
2012-06-03 17:01 ` Ken Brown
2012-06-06 11:05 ` Stephen L
2012-06-08 12:59 ` Ken Brown
2012-06-08 15:33 ` Achim Gratz
2012-06-08 16:46 ` Ken Brown [this message]
2012-06-08 19:35 ` Andrey Repin
2012-06-11 0:45 ` Ken Brown
2012-06-11 2:54 ` Yaakov (Cygwin/X)
2012-06-11 11:39 ` Ken Brown
2012-06-11 15:11 ` Ken Brown
2012-06-12 13:02 ` Ken Brown
2012-06-11 13:56 ` K Stahl
2012-06-11 14:54 ` Ken Brown
2012-06-11 16:15 ` K Stahl
2012-06-11 17:59 ` Ken Brown
2012-06-11 18:56 ` K Stahl
2012-06-13 18:40 ` Ken Brown
2012-06-13 21:07 ` Ken Brown
2012-06-13 21:40 ` Christopher Faylor
2012-06-14 19:19 ` Ryan Johnson
2012-06-14 19:48 ` Ken Brown
2012-06-13 23:58 ` K Stahl
-- strict thread matches above, loose matches on Subject: below --
2012-06-05 6:29 Pach Roman (DGS-EC/ESG2)
[not found] <AF5E26A9B961BF4681B5C1593D7D03C020AFDD6C1D@SI-MBX06.de.bosch.com>
2012-06-04 15:49 ` Ken Brown
2012-06-01 6:17 Pach Roman (DGS-EC/ESG2)
2012-06-01 23:14 ` Ken Brown
2012-05-25 8:26 Angelo Graziosi
2012-05-30 11:26 ` Stephen L
2012-05-30 14:39 ` Ken Brown
2012-05-31 11:09 ` Stephen L
2012-05-31 13:06 ` Ken Brown
2012-05-24 12:37 Berglund Magnus (SE)
2012-05-24 13:01 ` Ken Brown
2012-05-24 14:51 ` K Stahl
2012-05-25 14:35 ` Ken Jackson
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=4FD22C39.6070107@cornell.edu \
--to=kbrown@cornell.edu \
--cc=cygwin@cygwin.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
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 read-only IMAP folder(s) and NNTP newsgroup(s).