Re: "git rebase" loses the additional changes in "evil" merges

From: Dale Worley <worley@c-66-31-108-177.hsd1.ma.comcast.net>
Date: Mar 5, 2013, 21:18 UTC
Message-ID: <201303052118.r25LIoAC000463@freeze.ariadne.com>
In-Reply-To: <7vtxoqx3s1.fsf@alter.siamese.dyndns.org>

Show 6 quoted lines

> From: Junio C Hamano <gitster@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 a way to "find
non-merge commits that haven't been applied yet", but rather (as
described in the git-rebase manual page):
 
    git-rebase - Forward-port local commits to the updated upstream head

    All changes made by commits in the current branch but that are not
    in <upstream> are saved to a temporary area. [...]  The commits
    that were previously saved into the temporary area are then
    reapplied to the current branch, one by one, in order.

Now if you read far enough down the page, I'm sure it warns about merge commits. But the stated basic *intention* is to replicate the existing branch, re-rooted at a new place on the upstream branch.

The current implementation fails this intention by losing changes made in merges. It fails this intention in a *dangerous* way by causing changes to be lost without warning.

Dale