From: Johannes Sixt <j.sixt@viscovery.net>
To: Shuang He <shuang.he@intel.com>
Cc: Christian Couder <christian.couder@gmail.com>,
"git@vger.kernel.org" <git@vger.kernel.org>,
"apenwarr@gmail.com" <apenwarr@gmail.com>
Subject: Re: [RFC] Add bad-branch-first option for git-bisect
Date: Mon, 24 Jan 2011 11:50:49 +0100 [thread overview]
Message-ID: <4D3D5989.50903@viscovery.net> (raw)
In-Reply-To: <4D3D54D3.7040801@intel.com>
Am 1/24/2011 11:30, schrieb Shuang He:
> It's recursively applying bad branch first algorithm, not just constantly
> stick to first parent.
> Given this condition:
> A -> B -> C -> D -> E -> F -> G -> H (master)
> \ a -> b -> c -> d -> e / (feature 1)
> \ x -> y -> z/ (feature 2)
> start with H as bad commit, and A as good commit, if y is the target bad
> commit. bad-branch-first algorithm will do it like this:
> 1. In first round stick to master branch, so it will locate G as first
> bad commit
> 2. In second round stick to feature1 branch, then it will locate d as
> first bad commit
> 3. In third round stick to feature2 branch, then it will finally
> locate y as first bad commit
> So you could see, it's always sticking to branch where current bad commit sit
Ok, so you explain what your algorithm does.
But you did not illustrate your problem. The history above is ordinary,
somewhat branchy, has *ONE* commit that introduces a regression, and *NO*
commit that fixes the regression. But in your rationale you said something
about "feature1 is fixed just a moment later after feature2 branch is
created". How does this fit into the picture, where is the problem, and
how does your algorithm solve it?
-- Hannes
next prev parent reply other threads:[~2011-01-24 10:51 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-01-24 2:03 [RFC] Add bad-branch-first option for git-bisect Shuang He
2011-01-24 2:05 ` [PATCH] add config option core.bisectbadbranchfirst Shuang He
2011-01-24 9:53 ` [RFC] Add bad-branch-first option for git-bisect Christian Couder
2011-01-24 10:30 ` Shuang He
2011-01-24 10:50 ` Johannes Sixt [this message]
2011-01-24 11:05 ` Shuang He
2011-01-24 20:04 ` Junio C Hamano
2011-01-25 3:27 ` Shuang He
2011-01-25 9:20 ` Christian Couder
2011-01-26 7:22 ` Shuang He
2011-01-26 9:44 ` Christian Couder
2011-01-26 10:40 ` Shuang He
2011-01-24 20:28 ` Avery Pennarun
2011-01-26 7:11 ` Shuang He
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=4D3D5989.50903@viscovery.net \
--to=j.sixt@viscovery.net \
--cc=apenwarr@gmail.com \
--cc=christian.couder@gmail.com \
--cc=git@vger.kernel.org \
--cc=shuang.he@intel.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 NNTP newsgroup(s).