From: "Junio C Hamano" <gits...@pobox.com>
Sent: Tuesday, March 05, 2013 9:35 PM
Dale Worley <wor...@c-66-31-108-177.hsd1.ma.comcast.net> writes:
From: Junio C Hamano <gits...@pobox.com>
I think this is to be expected for "git rebase", as it does not even
look at merges. It is a way to find non-merge commits that haven't
been applied yet, and apply them to the upstream to create a new
linear history.
I disagree. "git rebase" is not characterized as ...
The intention has always been "I have these patches, some were
applied upstream already, now what do I have left?".
Given that many folk appear to trip up with their rebase mindset, does
this suggest that a few tweaks to the manual may be in order to stop
such misunderstandings?
Perhaps:
git-rebase - Forward-port local commits, not in upstream,
to the updated upstream head
and to avoid "hidden" asides, add a few more paragraph breaks into the
description texts, and perhaps bring the "Note that any commits in HEAD
which introduce the same textual changes as a commit in HEAD..<upstream>
are omitted" sentence nearer the start.
That is, don't let folks get a too simplistic view of rebase, missing
its
hidden powers.
You do realize that you are disagreeing with somebody who designed
the original "git rebase" (before the --preserve-merges was added),
do you?
However the broader userbase brings with it a better class of fool ;-)
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
