From: Boyd Stephen Smith Jr. Date: Mon, 29 Dec 2008 22:21:31 GMT Subject: Re: rebase -i: learn to rebase root commit Message-ID: <200812291621.35732.bss@iguanasuicide.net> In-Reply-To: <200812292249.45900.trast@student.ethz.ch> On Monday 2008 December 29 15:49:42 Thomas Rast wrote: > Thomas Rast wrote: > > Teach git-rebase -i a new option --root, which instructs it to rebase > > the entire history leading up to . This is mainly for > > symmetry with ordinary git-rebase; it cannot be used to edit the root > > commit in-place (it requires --onto). > > Actually, I forgot the "rebase -i -p" code path, which dies if --root > is used with -p. Apologies. > > So for now, consider this broken and RFC: is there any sensible > use/interpretation of -p --root that I'm missing? Or should it just > disallow this combination? 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 " was specified instead of "--onto=NEW_ROOT^ --root ". 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. -- Boyd Stephen Smith Jr. ,= ,-_-. =. bss@iguanasuicide.net ((_/)o o(\_)) ICQ: 514984 YM/AIM: DaTwinkDaddy `-'(. .)`-' http://iguanasuicide.net/ \_/