From: Johannes Sixt <j.sixt@viscovery.net>
To: Junio C Hamano <gitster@pobox.com>
Cc: Greg Price <price@ksplice.com>,
git@vger.kernel.org, Stephen Haberman <stephen@exigencecorp.com>
Subject: Re: [PATCH] Fix rebase -p --onto
Date: Fri, 17 Jul 2009 10:40:08 +0200 [thread overview]
Message-ID: <4A6038E8.1090402@viscovery.net> (raw)
In-Reply-To: <7vk52767el.fsf@alter.siamese.dyndns.org>
Junio C Hamano schrieb:
> Johannes Sixt <j.sixt@viscovery.net> writes:
>
>> Greg Price schrieb:
>>> In a rebase with --onto, the correct test for whether we can skip
>>> rewriting a commit is if it is already on top of $ONTO, not $UPSTREAM.
>>> Without --onto, this distinction does not exist and the behavior does
>>> not change.
>>>
>>>
>>> In the situation
>>>
>>> X---o---o---o---M
>>> \ /
>>> x---x---x---x
>>>
>>> Y
>>> ...
>>> The command `git rebase -p --onto Y X M` moves only the
>>> first-parent chain, like so:
>>>
>>> X
>>> \
>>> x---x---x---x
>>> \
>>> Y---o'--o'--o'--M'
>>>
>>> because it mistakenly drops the other branch(es) x---x---x---x from
>>> the TODO file. This tests and fixes this behavior.
>> I think the current behavior is by design. There is nothing to fix.
>>
>> The purpose of rebase -p is to leave non-first children alone and rebase
>> only the first child parenthood chain. It is not the purpose to reseat an
>> entire history DAG.
>
> Hmm, if the original history were
>
> .---X---o---o---o---M
> \ /
> x---x---x---x---x
>
> Y
>
> and the rebase is about moving history leading to M since X on top of Y,
> I would actually have agreed that this
>
> .---X---o---o---o---M
> \ /
> x---x---x---x---x
> \
> Y---o'--o'--o'--M'
>
> would be the right thing to do (IOW, I would agree with you).
>
> Can the current code distinguish the two cases? More generally, can we
> always tell these two cases apart, or is it fundamentally not possible to
> differentiate the two cases and we should simplify the problem space by
> limiting ourselves by treating the first parent in a special way?
I have used rebase -i -p in the past to rewrite history that involves
merges of topic branches like this:
---------Y--M--M--F <-- master
/ /
----a--a--a /
/
--b--b--b--b
where F is a fixup that I want to insert between Y and M, and I thought
rebase -i -p was intended for this use-case.
With this in mind, I do not see why should we distinguish the cases. I
would even go so far to say that this is OK:
X---a---o---o---M X---a
\ / ===> \
x---x---x x---x---x
\
Y Y---a'--o'--o'--M'
next prev parent reply other threads:[~2009-07-17 8:40 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-07-16 23:00 [PATCH] Fix rebase -p --onto Greg Price
2009-07-17 6:38 ` Johannes Sixt
2009-07-17 8:27 ` Junio C Hamano
2009-07-17 8:40 ` Johannes Sixt [this message]
2009-07-17 8:47 ` Johannes Sixt
2009-07-17 16:48 ` Greg Price
2009-07-17 18:32 ` Johannes Schindelin
2009-07-17 19:00 ` Greg Price
2009-07-17 16:33 ` Greg Price
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=4A6038E8.1090402@viscovery.net \
--to=j.sixt@viscovery.net \
--cc=git@vger.kernel.org \
--cc=gitster@pobox.com \
--cc=price@ksplice.com \
--cc=stephen@exigencecorp.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).