git@vger.kernel.org mailing list mirror (one of many)
 help / color / mirror / code / Atom feed
From: Shuang He <shuang.he@intel.com>
To: git@vger.kernel.org
Cc: shuang.he@intel.com
Subject: [RFC] Add bad-branch-first option for git-bisect
Date: Mon, 24 Jan 2011 10:03:37 +0800	[thread overview]
Message-ID: <4D3CDDF9.6080405@intel.com> (raw)

Hi
      The default git-bisect algorithm will jump around the commit tree,
on the purpose of taking least steps to find the first culprit commit.
We may find it sometime would locate a old culprit commit that we're not
concerned about anymore.
      In most software development, there's one or two main branch which
is maintained for release, and a bunch of feature branches are created
for new feature development or bug fix.  For the reason that sometime
git-bisect will locate a old culprit commit would be:
          1. Quality of those branches may not match the main branch,
some functionality are broken at first and fixed later on the feature
branch. If git-bisect jump to there by chance, git-bisect will only find that old
culprit commit which only exists on that feature branch
          2. Some of those branches may not synchronized with main
branch in time.  Say feature1 is broken when feature2 branch is created, and
feature1 is fixed just a moment later after feature2 branch is created,
and when feature2's development is done, and developer want to merge
feature2 branch back to master branch, feature2 will be firstly
synchronized to master branch tip, then merge into master.  For the same
reason addressed in issue 1, this will also lead git-bisect into wrong
direction.

      In all, we think we do not care about branches that we're not
currently working, unless we're sure the regression is caused by that
branch.

      To address those issue, we propose to add a new config option:
          core.bisectbadbranchfirst::
              With this algorithm, git-bisect will always try to select
commits
              that on the same branch current bad commit sits. And will
fall back
              to default git-bisect algorithm when bad-branch-first
algorithm does
              not apply
          +
          This setting defaults to "false".

      The draft patch will be sent out in a later email, so it could be
reviewed inline.
      Any question or suggestion is welcome  :-)

Thanks
      --Shuang

             reply	other threads:[~2011-01-24  2:03 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-01-24  2:03 Shuang He [this message]
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
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

  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=4D3CDDF9.6080405@intel.com \
    --to=shuang.he@intel.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).