From: Chris Webb <chris@arachsys.com>
To: Junio C Hamano <gitster@pobox.com>
Cc: Jeff King <peff@peff.net>, git@vger.kernel.org
Subject: Re: Editing the root commit
Date: Sat, 23 Jun 2012 08:20:17 +0100 [thread overview]
Message-ID: <20120623072017.GI25478@arachsys.com> (raw)
In-Reply-To: <7vhau3m06e.fsf@alter.siamese.dyndns.org>
Junio C Hamano <gitster@pobox.com> writes:
> If you are doing "rebase -i --root", what does it _mean_ to reorder
> commits and move the root commit to somewhere else, or insert
> something else that is _not_ the root to the beginning of the
> sequence?
>
> It does not make _any_ sense to me. For one thing, the root commit
> is to replay "addition of all these paths" to void (if you were doing
> "rebase -i --root --onto $there", then $there may not be a void, but
> it needs not to have overlapping paths for the result to make any
> sense), and moving it to somewhere _other than_ the root location
> does not make much sense. For another, a non-root commit is mostly
> replay "these changes to these existing paths", and replaying such a
> change to a void does not make any sense either.
As you say, it depends on the commits you're re-ordering, but in my case the
first few commits were entirely additions, and I wanted to add these files
in a different order, and add different batches at once, with more sensible
commit messages to explain to the reader what was going on. The addition of
COPYING from quite a long way forward needed to move right back into the
first commit too.
> So in that sense, perhaps
>
> rebase -i --root
>
> in a history
>
> A---B---C
>
> should behave as if you did
>
> rebase -i A
>
> got an insn sheet that looked like
>
> pick B
> pick C
>
> and then you made it to look like
>
> exec false
> pick B
> pick C
>
> to get the control back when the HEAD is detached at A, in order for
> you to muck with the tree and "git commit --amend" to reword the
> message.
That would be easier to implement, certainly, but it makes --root --onto
inconsistent with --root without --onto, which does work 'in the standard
way' at present. It's also just a bit of syntactic sugar for something you
can already do with rebase -i at present, in exactly the way you describe
above.
Maybe it's the best I can sensibly do though. I'm away this weekend, but
will see what I can cook up one way or the other next week when the round
tuit supply is topped up!
Cheers,
Chris.
next prev parent reply other threads:[~2012-06-23 7:21 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
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 [this message]
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=20120623072017.GI25478@arachsys.com \
--to=chris@arachsys.com \
--cc=git@vger.kernel.org \
--cc=gitster@pobox.com \
--cc=peff@peff.net \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.