Re: rebase -i: learn to rebase root commit

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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: signature.asc
Description: This is a digitally signed message part.


[Index of Archives]     [Linux Kernel Development]     [Gcc Help]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [V4L]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Fedora Users]

  Powered by Linux