Re: In favor of "git commit --no-parent"

From: Phil Hord <phil.hord@gmail.com>
Date: Sep 29, 2011, 21:02 UTC
Message-ID: <CABURp0q4wi5ruLmeaZtN=8QvuX2ftSFQo1uJL0_8-wtm1nYaGA@mail.gmail.com>
In-Reply-To: <7vmxdnte0j.fsf@alter.siamese.dyndns.org>

On Thu, Sep 29, 2011 at 2:11 PM, Junio C Hamano <gitster@pobox.com> wrote: [...]

Show 14 quoted lines

> Step back a bit. There are two independent issues:
>
>  - When does it make sense to originate two independent histories in a
>   single repository that has a working tree?
>
>  - What is the best tool to originate a new independent history in a
>   single repository that has a working tree?
>
> As I said number of times already, be it done with "checkout --orphan" or
> "commit --no-parent", the "Separate History" use case is better done in a
> separate repository. There is *no* advantage to originate the two separate
> histories that do not share any resemblance of tree shape as branches in a
> single repository with a working tree; "git checkout $branch" between the
> two would actively work against you.

I think a user looking for this functionality -- either a new git user or a user who seldom uses the "create secondary root commit" command -- would first try 'git help init'. It seems logical to me that I should be able to do this:

 cd my-git-repo
 git init --root=<newbranch> .

This feels natural to me for this operation.

And it doesn't add "dangerous options" to the more commonly used commands (checkout, commit)

[...]

> That leaves "Hidden History" the only useful use case. IOW, the answer to
> the first question above is not "Separate or Hidden History", but is
> "Hidden History and nothing else".

I think you're saying that the "hidden history" scenario is more
special than the "separate history" one because of these reasons:
1. It is already possible to create a "hidden history".

And that's it. No more reason than that.

But isn't it also possible already to create a "separate history" just as easily? I can think of at least three methods that do not involve git-reset. And I'm a relative newbie.

> And a half of the the answer to the second question is "checkout --orphan"
> (and the other half would be "filter-branch"). "checkout --orphan" does
> have major safety advantage than introducing "commit --no-parent", as Peff
> pointed out earlier (to which I agreed).

The thing I don't understand about "checkout --orphan" is exactly what you're getting when you do this. I assume you get a populated index and a non-existent HEAD. This seems a lot like "git init" to me, especially in the non-existent HEAD area.

I didn't think git init would be much use for this scenario before, but now I've changed my mind.

 git init --root=<newbranch> --keep-index

Again, this avoids complicating the common commands. But maybe it does overload init with extra baggage.

>From this user's perspective it still makes more sense.

Phil

p.s. Sorry for jumping in so late.