git.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Thomas Rast <trast@student.ethz.ch>
To: git@vger.kernel.org
Cc: "Boyd Stephen Smith Jr." <bss@iguanasuicide.net>
Subject: Re: rebase -i: learn to rebase root commit
Date: Tue, 30 Dec 2008 13:23:27 +0100	[thread overview]
Message-ID: <200812301323.30550.trast@student.ethz.ch> (raw)
In-Reply-To: <200812291621.35732.bss@iguanasuicide.net>

[-- Attachment #1: Type: text/plain, Size: 2042 bytes --]

Boyd Stephen Smith Jr. wrote:
> Here's the interpretation that *I* come up with for -p --root used together:
> The commit with no parents (OLD_ROOT) is rebased as if -p were not given, call 
> the resulting commit NEW_ROOT.  Then, the rebase continues as if "--onto 
> NEW_ROOT OLD_ROOT <branch>" was specified instead of "--onto=NEW_ROOT^ --root 
> <branch>".

I like this logic, but it feels inconsistent as soon as there are
several root commits.  (This may be somewhat academic, since any repo
with several roots should also be able to cope with a merge...)

Some digging into the -p code shows that it knows which commits were
rewritten, and which were untouched.  It rewrites such that _all_
commits in $(git merge-base --all $branch $upstream) are rewritten to
look like $onto instead, i.e., all their occurrences in parent lists
of commits are rewritten to $onto.  All other commits are only
rewritten if they have a parent that was rewritten.

So I think one sane way is to define a virtual parent 'root', and
think of parentless commits as having the (sole) parent 'root'.  Then
we can rewrite such that 'root' becomes $onto, i.e., all occurrences
of 'root' in parent lists become $onto, consistent with the normal
operation.  (For the other commits, the same rule as above is
applied.)

Of course this just boils down to saying that _all_ root commits
reachable from $branch are rewritten to have $onto as their parent.
Subsequently, all other commits will also be rewritten because they
all must have at least one rewritten parent.

> Basically, --root only changes how the first commit is handled, which I think 
> is consistent with other uses of --root.  It's also similar to cherry-picking 
> the first commit, follwed by a non-root rebase, which I think is also 
> consistent with the intention of --root.

I believe this remark still holds if there is only a single root
commit on $branch.

I will reroll with an updated 2/3 shortly.

-- 
Thomas Rast
trast@{inf,student}.ethz.ch


[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 197 bytes --]

  reply	other threads:[~2008-12-30 12:24 UTC|newest]

Thread overview: 27+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-12-29 16:45 [PATCH 0/3] rebase --root Thomas Rast
     [not found] ` <cover.1230569041.git.trast@student.ethz.ch>
2008-12-29 16:45   ` rebase: learn to rebase root commit Thomas Rast
2008-12-29 16:45   ` rebase -i: " Thomas Rast
2008-12-29 21:49     ` Thomas Rast
2008-12-29 22:21       ` Boyd Stephen Smith Jr.
2008-12-30 12:23         ` Thomas Rast [this message]
2008-12-30 12:29           ` [PATCH v2 1/3] rebase: " Thomas Rast
2008-12-30 12:29             ` [PATCH v2 2/3] rebase -i: " Thomas Rast
2008-12-30 12:29               ` [PATCH v2 3/3] rebase: update documentation for --root Thomas Rast
2009-01-01 21:00             ` [PATCH v2 1/3] rebase: learn to rebase root commit Junio C Hamano
2009-01-02 18:58               ` Johannes Schindelin
2009-01-02 22:20               ` Thomas Rast
2009-01-02 22:28                 ` [PATCH v3 1/4] rebase -i: execute hook only after argument checking Thomas Rast
2009-01-02 22:28                   ` [PATCH v3 2/4] rebase: learn to rebase root commit Thomas Rast
2009-01-02 22:28                     ` [PATCH v3 3/4] rebase -i: " Thomas Rast
2009-01-02 22:28                       ` [PATCH v3 4/4] rebase: update documentation for --root Thomas Rast
2009-01-02 22:41                       ` [INTERDIFF v3 3/4] rebase -i: learn to rebase root commit Thomas Rast
2009-01-02 22:41                     ` [INTERDIFF v3 2/4] rebase: " Thomas Rast
2009-01-02 23:06                     ` [PATCH " Junio C Hamano
2009-01-02 23:45                       ` [PATCH v3.1] " Thomas Rast
2009-01-05 17:35                         ` [PATCH v3.2] " Thomas Rast
2009-01-06  8:19                           ` Junio C Hamano
2009-01-02 22:49                 ` [PATCH v2 1/3] " Junio C Hamano
2009-01-02 22:54                   ` Thomas Rast
2009-01-02 23:07                     ` Junio C Hamano
2008-12-30  8:22       ` rebase -i: " Junio C Hamano
2008-12-29 16:45   ` rebase: update documentation for --root Thomas Rast

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=200812301323.30550.trast@student.ethz.ch \
    --to=trast@student.ethz.ch \
    --cc=bss@iguanasuicide.net \
    --cc=git@vger.kernel.org \
    /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).