Re: [BUG] rebase -p loses commits

From: Junio C Hamano <gitster@pobox.com>
Date: May 17, 2011, 01:02 UTC
Message-ID: <7vk4dqi1fr.fsf@alter.siamese.dyndns.org>
In-Reply-To: <7vpqnii1sx.fsf@alter.siamese.dyndns.org>

Junio C Hamano <gitster@pobox.com> writes:

Show 8 quoted lines

> But the above "preserving" rewrite does not even preserve the topology of
> the graph (the original * is a true merge between two forks, but *' is
> not) to begin with.  Also, if you want to _usefully_ place F' on top of M,
> such a rewrite should resolve possible conflicts that was resolved at * in
> the original graph at F' anyway, which would mean that the resulting *'
> should become a totally empty commit.
>
> Why would anybody want to do such a thing to begin with?

Note that I am not saying "rebase -p" is not useful in general. If you had

         x---x---x---W---X
        /             \   \
    ---M               Y---Z

it is entirely sensible to want to have this history to exclude 'x'

         x---x---x---W---X
        /             \   \
    ---M---W'--X'      Y---Z
            \   \
             Y'--Z'

I think the patch I posted earlier should stop the problematic case Jeff mentioned from happening, but I am trying to see if it makes sense to stop without doing anything even when it is forced when onto and merge-base are the same commit (which is not true for this "sensible" case).