On Nov 10, 2007, at 9:25 PM, Junio C Hamano wrote:
Linus Torvalds <torvalds@xxxxxxxxxxxxxxxxxxxx> 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.
I propose to remove this suggestion if no one comes up with a
real world example where rebasing after the fact turned out to
be useful. If nobody has such an example it doesn't make sense
to tell readers of the manual that rebase could be useful in
such a situation.
The patch would be identical except for the last paragraph
removed.
Steffen
-
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
