From: Michael Witten <mfwitten@gmail.com>
Date: Thu, 29 Sep 2011 21:28:39 GMT
Subject: Re: In favor of "git commit --no-parent"
Message-ID: <CAMOZ1Bs9kei58AVJZRJM4g+Nh3QaY8dtUBctmLL8SVL3XW=aLw@mail.gmail.com>
In-Reply-To: <CABURp0q4wi5ruLmeaZtN=8QvuX2ftSFQo1uJL0_8-wtm1nYaGA@mail.gmail.com>

On Thu, Sep 29, 2011 at 21:02, Phil Hord <phil.hord@gmail.com> wrote:
> On Thu, Sep 29, 2011 at 2:11 PM, Junio C Hamano <gitster@pobox.com> wrote:
> [...]
>> 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.

That would be a good place for the "git checkout --no-parent" variant,
especially given that I think "git checkout --no-parent" should produce
an empty working tree and index, which we can all note is essentially
what "git init" gives us.

Your suggestion seems like a corroboration of my stance.