On Sun, Dec 23, 2012 at 11:18 AM, Junio C Hamano <gitster@xxxxxxxxx> wrote:
> Martin von Zweigbergk <martinvonz@xxxxxxxxx> writes:
>> On Sat, Dec 22, 2012 at 7:24 PM, Junio C Hamano <gitster@xxxxxxxxx> wrote:
>
> I am not opposed to an "internal use" of the cherry-pick machinery to
> implement a corner case of "rebase -i":
>....
> 3. You run "rebase -i --root" to get this insn sheet:
>
> pick Add Makefile and hello.c for "Hello world"
> pick Add goodbye.c for "Goodbye world"
>
> and swap them:
>
> pick Add goodbye.c for "Goodbye world"
> pick Add Makefile and hello.c for "Hello world"
Right, and as you point out in your later message, editing the initial
commit is another (and more useful) use case. It could of course be
special cased in "git rebase", but I think doing it "git cherry-pick"
is the right thing to do. Hopefully git-rebase.sh can then just reset
to the void state and git-rebase--interactive.sh can just continue
without knowing or caring whether it got started on an unborn branch.
Hmm... I just realized the "branch" in "unborn branch" really means we
don't have "unborn detached HEAD", do we? So some more tricks are
probably necessary after all. :-(
> [...] It transplants something that used to depend on the entire
> history behind it to be the beginning of the history so its log
> needs to be adjusted, but "rebase -i" can choose to always make it
> conflict and force the user to write a correct log message, so it
> won't expose the fundamental flaw you would add if you allowed the
> end-user facing "cherry-pick" to pick something to create a new root
> commit without interaction.
If I understand you correctly, you are suggesting that "git rebase"
should set the action from "pick" to "edit" for the first commit in
the insn sheet if it is not a root commit. "git rebase -i --root"
doesn't currently do that, but it certainly could.
> I agree that "git reset" without any commit parameter to reset the
> index and optionally the working tree (with "--hard") should reset
> from an empty tree when you do not yet have any commit.
Good to hear.
> But I do not think it has anything to do with "cherry-pick to empty",
> so I do not agree with "In the same way" at all.
See later comment.
>> One use case might be to rewrite history by creating an new unborn
>> branch and picking the initial commit and a subset of other commits.
>
> If you mean, in the above sample history, to "git cherry-pick" the
> commit that starts the "Hello world" and then do something else on
> top of the resulting history, how would that be different from
> forking from that existing root commit?
True, the result would be the same. The user's thought process might
be a little different ("let me start from scratch" vs "let me start
almost from scratch"), but that's a very minor difference that I'm
sure any user would quickly overcome.
>> Anyway, I didn't implement it because I thought it would be very
>> useful, but mostly because I just thought it should work (for
>> completeness).
>
> I would not exactly call X "complete" if X works in one way in most
> cases and it works in quite a different way in one other case, only
> because it would have to barf if it wanted to work in the same way
> as in most cases, and the different behaviour is chosen only because
> "X that does something is better than X that stops in an impossible
> situation and barfs".
I agree, of course, but I don't see the behavior as different. When
thinking about behavior around the root of the history, I imagine that
all root commits actually have a parent, and that they all have the
same parent. I also imagine that on an unborn branch, instead of being
invalid, HEAD points to that same "single root" commit with an empty
tree. Despite this model not matching git's, I find that this helps me
reason about what the behavior of various commands should be.
With this reasoning, cherry-picking into an unborn branch is no
different from cherry-picking into any commit with an empty tree
(which of course would be rare, but not forbidden).
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html