git@vger.kernel.org mailing list mirror (one of many)
 help / color / mirror / code / Atom feed
From: Junio C Hamano <gitster@pobox.com>
To: Hagen Paul Pfeifer <hagen@jauu.net>
Cc: git@vger.kernel.org
Subject: Re: Bisect limited to Merge Commits
Date: Wed, 27 Apr 2016 13:56:42 -0700	[thread overview]
Message-ID: <xmqq8tzy93ed.fsf@gitster.mtv.corp.google.com> (raw)
In-Reply-To: <20160427204551.GB4613@virgo.localdomain> (Hagen Paul Pfeifer's message of "Wed, 27 Apr 2016 22:45:51 +0200")

Hagen Paul Pfeifer <hagen@jauu.net> writes:

> Imagine a "rebase feature branch" style of development. All features are
> developed on separate features branch which are rebased on master and
> immediately merged into the upstream master. 

I do not want to imagine such ;-)  The only semi-sensible reason why
people might want to always rebase on top of 'master' is to keep the
history completely linear, so with such a workflow, there won't be a
merge commit.

But I think "rebase" part of your description is a red herring.  If
a development goes by always doing a new feature in a side branch
and then merge the branch only after it is done to the 'master'
branch, then bisecting only the commits on first-parent chain would
often be a quick first-pass to find the topic whose merge into the
'master' branch introduced a breakage.  From there you can dig down
to each individual commit on the side branch.  And for that, it is
immaterial that the side branch gets rebased on 'master' and forced
to become a merge with "--no-ff", of the side branch was developed
on older upstream but in a careless way full of "oops, previous one
I broke the entire world and it does not even compile; this commit
fixes it" commits.

So being able to stop at only commits on the first-parent chain is a
valid and useful tool.  "git bisect --first-parent" is one of the
things that are sometimes asked for.

  reply	other threads:[~2016-04-27 20:56 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-04-27 20:45 Bisect limited to Merge Commits Hagen Paul Pfeifer
2016-04-27 20:56 ` Junio C Hamano [this message]
2016-04-27 21:33   ` Johannes Sixt
2016-04-27 22:25     ` Junio C Hamano
2016-04-28  6:19     ` Hagen Paul Pfeifer
2016-04-28  6:44       ` Jacob Keller

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=xmqq8tzy93ed.fsf@gitster.mtv.corp.google.com \
    --to=gitster@pobox.com \
    --cc=git@vger.kernel.org \
    --cc=hagen@jauu.net \
    /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).