git.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Jeff King <peff@peff.net>
To: Junio C Hamano <gitster@pobox.com>
Cc: Chris Webb <chris@arachsys.com>, git@vger.kernel.org
Subject: Re: Editing the root commit
Date: Wed, 20 Jun 2012 15:29:38 -0400	[thread overview]
Message-ID: <20120620192938.GC31520@sigill.intra.peff.net> (raw)
In-Reply-To: <7vy5nhvo0z.fsf@alter.siamese.dyndns.org>

On Wed, Jun 20, 2012 at 11:25:32AM -0700, Junio C Hamano wrote:

> 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:

> 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.

  reply	other threads:[~2012-06-20 19:29 UTC|newest]

Thread overview: 29+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-06-19  9:16 Editing the root commit Chris Webb
2012-06-19 10:09 ` Junio C Hamano
2012-06-19 11:17   ` Chris Webb
2012-06-20  9:32     ` Chris Webb
2012-06-20 18:25       ` Junio C Hamano
2012-06-20 19:29         ` Jeff King [this message]
2012-06-20 19:39           ` Chris Webb
2012-06-20 19:48             ` Jeff King
2012-06-22 20:50               ` Chris Webb
2012-06-22 21:35                 ` Junio C Hamano
2012-06-22 22:02                   ` Chris Webb
2012-06-22 22:26                     ` Chris Webb
2012-06-22 22:50                       ` Junio C Hamano
2012-06-23  7:20                         ` Chris Webb
2012-06-26 15:04                 ` git-commit bug (was Re: Editing the root commit) Chris Webb
2012-06-26 15:06                   ` [PATCH] git-checkout: disallow --detach on unborn branch Chris Webb
2012-06-26 18:08                   ` git-commit bug Junio C Hamano
2012-06-26 13:33               ` Editing the root commit Chris Webb
2012-06-26 13:36                 ` [PATCH 1/2] rebase -i: support --root without --onto Chris Webb
2012-06-26 13:36                   ` [PATCH 2/2] Add tests for rebase -i " Chris Webb
2012-06-26 19:20                   ` [PATCH 1/2] rebase -i: support " Junio C Hamano
2012-06-26 19:38                     ` Chris Webb
2012-06-26 20:05                       ` Junio C Hamano
2012-06-26 20:11                         ` Chris Webb
2012-06-26 21:24                           ` Junio C Hamano
2012-06-26 21:27                             ` Chris Webb
2012-06-20 19:35         ` Editing the root commit Chris Webb
2012-06-25 17:22         ` Martin von Zweigbergk
2012-06-19 11:50 ` jaseem abid

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=20120620192938.GC31520@sigill.intra.peff.net \
    --to=peff@peff.net \
    --cc=chris@arachsys.com \
    --cc=git@vger.kernel.org \
    --cc=gitster@pobox.com \
    /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).