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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



From: "Junio C Hamano" <gitster@xxxxxxxxx>
Sent: Tuesday, March 05, 2013 9:35 PM
Dale Worley <worley@xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx> writes:

From: Junio C Hamano <gitster@xxxxxxxxx>

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 majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html


[Index of Archives]     [Linux Kernel Development]     [Gcc Help]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [V4L]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Fedora Users]