git.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Christian Borntraeger <borntraeger@de.ibm.com>
To: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Sam Ravnborg <sam@ravnborg.org>,
	Johannes Schindelin <Johannes.Schindelin@gmx.de>,
	git@vger.kernel.org,
	Linux Kernel Mailing List <linux-kernel@vger.kernel.org>
Subject: Re: current git kernel has strange problems during bisect
Date: Sun, 11 Jan 2009 22:39:20 +0100	[thread overview]
Message-ID: <200901112239.20306.borntraeger@de.ibm.com> (raw)
In-Reply-To: <alpine.LFD.2.00.0901111200330.6528@localhost.localdomain>

Am Sonntag 11 Januar 2009 schrieb Linus Torvalds:
> Well, you don't actually have to mark that semi-random one as good either. 
> What you can do is to just mark anything that _only_ contains fs/btrfs as 
> good. IOW, you don't have to know the magic number - you just have to be 
> told that "oh, if you only have btrfs files, and you're not actively 
> bisecting a btrfs bug, just do 'git bisect good' and continue".

That should work.

<rant>
Still, I am a bit frustrated. During this weekend I reported 2 regressions 
(wlan and ata)  and I still try to find out why suspend/resume stopped 
working. In the meantime I have identified 2 patches (one was already known, 
I reported the 2nd to the usb maintainers) after 2.6.28 that caused suspend 
to ram regressions. In rc1 S2R was broken again. So I tried bisecting the 
third patch - which finally brought me to the btrfs bisect problem.

For me, this was the most annoying  merge window ever.

In my opinion we should really avoid subtree merges in the future as a curtesy 
to people who do the uncool work of testing, problem tracking and bisecting. 
</rant>

Christian

  reply	other threads:[~2009-01-11 21:41 UTC|newest]

Thread overview: 23+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-01-11 15:02 current git kernel has strange problems during bisect Christian Borntraeger
2009-01-11 15:07 ` Christian Borntraeger
2009-01-11 15:14   ` Johannes Schindelin
2009-01-11 15:20     ` Christian Borntraeger
2009-01-11 16:31       ` Boaz Harrosh
2009-01-11 19:13       ` Linus Torvalds
2009-01-11 19:42         ` Sam Ravnborg
2009-01-11 19:47           ` Alexey Zaytsev
2009-01-11 23:02             ` Pierre Habouzit
2009-01-12  4:51               ` Christian Couder
2009-01-12  5:03                 ` Christian Couder
2009-01-11 20:04           ` Linus Torvalds
2009-01-11 21:39             ` Christian Borntraeger [this message]
2009-01-11 22:27               ` Daniel Barkalow
2009-01-13 20:26               ` Kyle Moffett
2009-01-15 16:54                 ` Andreas Bombe
2009-01-15 23:13                   ` Kyle Moffett
2009-01-11 21:54             ` Sam Ravnborg
2009-01-11 22:17             ` Alexey Zaytsev
2009-01-11 22:32               ` Sam Ravnborg
2009-01-11 22:34               ` Daniel Barkalow
2009-01-11 20:29         ` Andi Kleen
2009-01-11 20:51           ` Johannes Schindelin

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=200901112239.20306.borntraeger@de.ibm.com \
    --to=borntraeger@de.ibm.com \
    --cc=Johannes.Schindelin@gmx.de \
    --cc=git@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=sam@ravnborg.org \
    --cc=torvalds@linux-foundation.org \
    /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 NNTP newsgroup(s).