From: Junio C Hamano <gitster@pobox.com>
To: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Steffen Prohaska <prohaska@zib.de>,
Benoit Sigoure <tsuna@lrde.epita.fr>,
Andreas Ericsson <ae@op5.se>,
Johannes Sixt <j.sixt@viscovery.net>,
git@vger.kernel.org
Subject: Re: [PATCH v4] user-manual: Add section "Why bisecting merge commits can be harder ..."
Date: Sat, 10 Nov 2007 12:25:22 -0800 [thread overview]
Message-ID: <7vtzntlufh.fsf@gitster.siamese.dyndns.org> (raw)
In-Reply-To: <alpine.LFD.0.999.0711101105340.15101@woody.linux-foundation.org> (Linus Torvalds's message of "Sat, 10 Nov 2007 11:10:51 -0800 (PST)")
Linus Torvalds <torvalds@linux-foundation.org> writes:
> On Sat, 10 Nov 2007, Steffen Prohaska wrote:
>> +
>> +But if you already made a merge C instead of rebasing, all
>> +is not lost. In the illustrated case, you can easily rebase
>> +one parent branch on top of the other after the fact, just
>> +to understand the history and to make the history more
>> +easily to bisect.
>
> I simply don't think this is true.
>
> You can *not* easily rebase after the fact. Both the parents may have lots
> of merges independently of each other, and rebase won't be able to do
> *anything* with such a case. In fact, the only reason you think you can
> easily rebase after-the-fact is that you made the example history be
> trivial. In real life, if the example history is that trivial (just a
> single merge of two otherwise linear histories), you'd probably generally
> not have this problem in the first place.
>
> The facts are:
>
> - git bisect can handle merges quite well, and points to the right
> commit (which is *usually* not a merge).
>
> - but merges by definition introduce changes from two independent lines
> of development, and while both lines may work well on their own, it is
> possible that (a) the merge itself was done incorrectly or (b) the two
> (or more) features that were introduced simply clash.
>
> - "git rebase" won't do a thing for this after the fact, except in
> trivial cases, and even then it will generate a new history that simply
> isn't compatible with the original history, so while it could in theory
> help bisect things further in some limited and simple cases, in general
> it's simply not that useful an approach.
>
> ..and I think it's simply wrong to even *try* to imply that "git rebase"
> can somehow change any of this.
Very true. It is a suggestion useful _only_ when you can easily
rebase. Like the one illustrated in the description, which is
artificial and of very limited scope. If you cannot rebase
easily, then (by definition) rebase would not help you.
next prev parent reply other threads:[~2007-11-10 20:25 UTC|newest]
Thread overview: 30+ messages / expand[flat|nested] mbox.gz Atom feed top
2007-11-04 9:16 [PATCH] user-manual: add advanced topic "bisecting merges" Steffen Prohaska
2007-11-04 11:23 ` Ralf Wildenhues
2007-11-07 21:50 ` [PATCH v2] " Steffen Prohaska
2007-11-07 22:16 ` Benoit Sigoure
2007-11-07 22:26 ` J. Bruce Fields
2007-11-08 6:40 ` Steffen Prohaska
2007-11-08 7:19 ` Johannes Sixt
2007-11-08 8:59 ` Steffen Prohaska
2007-11-08 9:11 ` Johannes Sixt
2007-11-08 9:33 ` Andreas Ericsson
2007-11-08 9:53 ` Johannes Sixt
2007-11-08 12:54 ` Steffen Prohaska
2007-11-08 13:22 ` Johannes Sixt
2007-11-08 14:55 ` Steffen Prohaska
2007-11-10 9:48 ` [PATCH v3] " Steffen Prohaska
2007-11-10 10:36 ` Junio C Hamano
2007-11-10 11:16 ` Steffen Prohaska
2007-11-10 13:49 ` [PATCH v4] user-manual: Add section "Why bisecting merge commits can be harder ..." Steffen Prohaska
2007-11-10 19:10 ` Linus Torvalds
2007-11-10 20:25 ` Junio C Hamano [this message]
2007-11-10 22:41 ` Steffen Prohaska
2007-11-18 3:59 ` J. Bruce Fields
2007-11-18 9:47 ` Steffen Prohaska
2007-11-18 23:18 ` J. Bruce Fields
2007-11-08 13:38 ` [PATCH v2] user-manual: add advanced topic "bisecting merges" Andreas Ericsson
2007-11-08 14:51 ` Benoit Sigoure
2007-11-08 15:07 ` Steffen Prohaska
2007-11-08 15:23 ` Johannes Schindelin
2007-11-08 18:38 ` Brian Gernhardt
2007-11-04 13:50 ` [PATCH] " Benoit SIGOURE
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=7vtzntlufh.fsf@gitster.siamese.dyndns.org \
--to=gitster@pobox.com \
--cc=ae@op5.se \
--cc=git@vger.kernel.org \
--cc=j.sixt@viscovery.net \
--cc=prohaska@zib.de \
--cc=torvalds@linux-foundation.org \
--cc=tsuna@lrde.epita.fr \
/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).