Re: Editing the root commit
- From
Jeff King <peff@peff.net>
- Date
- Jun 20, 2012, 19:29 UTC
- Message-ID
- <20120620192938.GC31520@sigill.intra.peff.net>
- In-Reply-To
- <7vy5nhvo0z.fsf@alter.siamese.dyndns.org>
On Wed, Jun 20, 2012 at 11:25:32AM -0700, Junio C Hamano wrote:
Show 9 quoted lines
> What if we do not say --onto here? I am not asking what the current > implementation does (we get an error message saying "I want 'onto' > specified"). What _should_ this command mean to a naïve user? > > $ git rebase [-i] --root > > I think it should mean "replay all my history down to root". The > original root commit should become the new root commit in the > rewritten history.
I think that is the only thing that makes sense. And it should be easy with non-interactive rebase, because we always start with the root commit, and it always applies cleanly.
For interactive rebase, though, it's a little trickier. Earlier you said:
Show 6 quoted lines
> For the root commit in the history, you check it out on the detached > HEAD. Under "--interactive" if the insn sheet tells you to allow > the user to "edit/amend/reword" it, give control back the user after > you have detached HEAD at that commit. The user experience should > be identical to the case you are replaying on an existing commit > after that point.
That makes sense if the first instruction involves picking that first commit. But if the first commit is deleted (or reordered), then it is not appropriate to detach to the root; we must detach to the first picked commit, which we can only do after we see the final instruction sheet.
Git-rebase tries to do the rewind before dropping to run_specific_rebase. However, I think we might be OK, as it seems that there is a special exception for "interactive", and we drop to run_specific_rebase early in that case.
-Peff
PS I have no clue how multiple roots would do. Without --preserve merges, I would except history to be flattened, and that should be OK (the root commit will become a non-root, just as it would if you were actually going --onto something else). But I suspect --preserve-merges might be tricky, as you might have to create several root commits during the course of processing the instruction sheet.