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 <branch>. 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 <branch>" was specified instead of "--onto=NEW_ROOT^ --root <branch>". 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@xxxxxxxxxxxxxxxxx ((_/)o o(\_)) ICQ: 514984 YM/AIM: DaTwinkDaddy `-'(. .)`-' http://iguanasuicide.net/ \_/
Attachment:
signature.asc
Description: This is a digitally signed message part.
