From: Andreas Ericsson <ae@op5.se>
To: "Ævar Arnfjörð Bjarmason" <avarab@gmail.com>
Cc: Git Mailing List <git@vger.kernel.org>
Subject: Re: Why can't I use git-bisect to find the first *good* commit?
Date: Mon, 28 Mar 2011 12:39:05 +0200 [thread overview]
Message-ID: <4D906549.9050102@op5.se> (raw)
In-Reply-To: <AANLkTinQ0rCw2ydisHra779r6_iSOxqRwOStpJrNbx7h@mail.gmail.com>
On 03/28/2011 11:32 AM, Ævar Arnfjörð Bjarmason wrote:
> Something was broken a 100 revisions ago, has now been fixed, but I
> want to find when it was fixed.
>
> I'd expect this to work:
>
> $ git bisect start
> $ git bisect good
> $ git bisect bad HEAD~100
> Some good revs are not ancestor of the bad rev.
> git bisect cannot work properly in this case.
> Maybe you mistake good and bad revs?
>
> But instead I have to do:
>
> $ git bisect start
> $ git bisect bad
> $ git bisect good HEAD~100
>
> And then proceed to mark good revisions as bad, and bad revisions as
> good.
>
> That works, but it's very confusing.
>
> Why can't bisect just do the right thing here and accept that your
> more recent revesion is the good one, and the old one is the bad one?
It's due to the fact that bisect is, in 99% of the cases, used to
locate the commit that introduced a bug and the implementation details
naturally gear towards that scenario, with fixed names that do the
Right Thing(tm) in 99% of all cases.
--
Andreas Ericsson andreas.ericsson@op5.se
OP5 AB www.op5.se
Tel: +46 8-230225 Fax: +46 8-230231
Considering the successes of the wars on alcohol, poverty, drugs and
terror, I think we should give some serious thought to declaring war
on peace.
next prev parent reply other threads:[~2011-03-28 10:39 UTC|newest]
Thread overview: 23+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-03-28 9:32 Why can't I use git-bisect to find the first *good* commit? Ævar Arnfjörð Bjarmason
2011-03-28 10:39 ` Andreas Ericsson [this message]
2011-03-28 12:22 ` code.sculptor
2011-03-28 12:58 ` Matthieu Moy
2011-03-28 12:39 ` Vincent van Ravesteijn
2011-03-28 14:04 ` Christian Couder
2011-03-28 14:29 ` Andrew Garber
2011-03-28 14:40 ` Johannes Sixt
2011-03-28 17:18 ` Andrew Garber
2011-03-28 17:33 ` Matthieu Moy
2011-03-28 17:45 ` Andrew Garber
2011-03-28 17:55 ` Matthieu Moy
2011-03-28 18:12 ` Andrew Garber
2011-03-28 18:23 ` Matthieu Moy
2011-03-28 18:57 ` demerphq
2011-03-28 19:12 ` Andrew Garber
2011-03-28 19:40 ` Matthieu Moy
2011-03-28 20:12 ` Andrew Garber
2011-03-28 20:25 ` Jeff King
2011-03-28 21:25 ` Jeff King
2011-03-28 20:37 ` Matthieu Moy
2011-03-29 10:54 ` Andreas Ericsson
2011-05-22 19:41 ` Michael Witten
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
List information: http://vger.kernel.org/majordomo-info.html
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=4D906549.9050102@op5.se \
--to=ae@op5.se \
--cc=avarab@gmail.com \
--cc=git@vger.kernel.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.
Code repositories for project(s) associated with this public inbox
https://80x24.org/mirrors/git.git
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).