git.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Stephen Haberman <stephen@exigencecorp.com>
To: Andrew Wong <andrew.w@sohovfx.com>
Cc: Junio C Hamano <gitster@pobox.com>,
	Andrew Wong <andrew.kw.w@gmail.com>,
	git@vger.kernel.org
Subject: Re: [PATCH] rebase -i -p: doesn't pick certain merge commits that are children of "upstream"
Date: Sat, 18 Jun 2011 10:17:18 -0500	[thread overview]
Message-ID: <20110618101718.6ff03688@sh9> (raw)
In-Reply-To: <4DFC4863.2090803@sohovfx.com>


> In commit a4f25e3, we could already rebase B1 and squash F1 onto D1, 
> while reusing C1 and recreating the merge. That means we could
> already pass t3411.2if we adjusted the todo-list to account for the
> extra "pick C1" line.

You're right. I was wrong about that.

> Slightly off-topic, but I believe the branches will remain intact as
> long as the branch commits remain in the same topo-order relative to
> each other in the todo-list.

If in topo-order, yeah, I guess that is right.

> i.e. git will be confused if we try to move a commit from one branch
> into the other.

Right. If I do `rebase -i -p B1` and in the todo put C1 after F1, I get
a fatal message that E1 cannot be cherry picked.

Given rebase-i-p's limited ability to reorder graphs, e.g. the error
above, my understanding was that, when -p is used, only first-parent
changes should be in the todo. This straight line, non-graph list does
limit what the user can do, but, AFAIK, the benefit is that rebase-i-p
can then actually handle any given reordering of the todo.

Letting C1 into the todo would mean having to explain to the user why
some of their reorderings worked and others didn't. Or else making
rebase-i-p smart enough to handle all cases. Which, IIRC, was something
considered unlikely just given the fact that todo is flat and there
isn't a way for the user to express topo reorderings. At the time,
there was talk of another rewriting tool that would use marks and
other hints to handle graphs and it was considered what, if anything,
would eventually handle complex rewrites like this.

I think that Jeff's use case of rebase-i-p'ing C1, which is not on the
first-parent list of commits, should be an error as it delves into
territory (topo reordering) that rebase-i-p can't fully handle.

(If -p isn't used, just regular rebase, everything is being flattened,
so there is no concern of topo reordering, so things are a lot simpler
and C1 can/should be in the list.)

- Stephen

  reply	other threads:[~2011-06-18 15:17 UTC|newest]

Thread overview: 28+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-05-16 10:33 [BUG] rebase -p loses commits Jeff King
2011-05-16 19:42 ` Andrew Wong
2011-05-16 20:36 ` Junio C Hamano
2011-05-17  0:33   ` Andrew Wong
2011-05-17  0:54     ` Junio C Hamano
2011-05-17  1:02       ` Junio C Hamano
2011-05-17  5:44     ` Jeff King
2011-05-17 16:07       ` Andrew Wong
2011-05-17 16:12         ` Jeff King
2011-05-21  5:51           ` [RFC] Interactive-rebase doesn't pick all children of "upstream" Andrew Wong
2011-05-21  5:51             ` Andrew Wong
2011-05-21  7:34               ` Andrew Wong
2011-06-05  5:32           ` [PATCH] " Andrew Wong
2011-06-05  9:16             ` Johannes Sixt
2011-06-05 14:11               ` Andrew Wong
2011-06-07  4:08               ` [PATCH v2] rebase -i -p: doesn't pick certain merge commits that are " Andrew Wong
2011-06-07  4:08                 ` [PATCH] " Andrew Wong
2011-06-12 16:28                   ` Andrew Wong
2011-06-13 16:01                   ` Junio C Hamano
2011-06-13 17:30                     ` Andrew Wong
2011-06-16 22:24                       ` Stephen Haberman
2011-06-18  6:40                         ` Andrew Wong
2011-06-18 15:17                           ` Stephen Haberman [this message]
2011-06-18 16:47                             ` Andrew Wong
2011-06-18 17:12                               ` Stephen Haberman
2011-06-18 22:12                                 ` [PATCH] rebase -i -p: include non-first-parent commits in todo list Andrew Wong
2011-06-18 22:13                                 ` [PATCH] rebase -i -p: doesn't pick certain merge commits that are children of "upstream" Andrew Wong
2011-05-17  5:39   ` [BUG] rebase -p loses commits Jeff King

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=20110618101718.6ff03688@sh9 \
    --to=stephen@exigencecorp.com \
    --cc=andrew.kw.w@gmail.com \
    --cc=andrew.w@sohovfx.com \
    --cc=git@vger.kernel.org \
    --cc=gitster@pobox.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).