git.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
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'

  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).