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

From: Phil Hord <phil.hord@gmail.com>
Date: Sep 29, 2011, 22:07 UTC
Message-ID: <CABURp0rjBdx+=_8R5g16fNKWis3=GgJw9SQ9D53H6xu_-Tq3Uw@mail.gmail.com>
In-Reply-To: <7v4nzvrp3k.fsf@alter.siamese.dyndns.org>

Junio C Hamano <gitster@pobox.com> writes:

Show 16 quoted lines

> Phil Hord <phil.hord@gmail.com> writes:
>
>> 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.
>
> Hmm, this does not feel very natural to me; unless "git init --root=work"
> uses 'work' branch instead of 'master' when creating a new repository,
> that is. But it is attractive that init is much less often used than
> checkout/commit and everybody knows it is somewhat a _special_ operation.

That's what I meant. Sorry my example wasn't more clear about that. I also considered "--new-branch" and "--new-root". I like the latter more, but I didn't like the extra hyphen. Considering the rarity and the prior art, I guess either one is more clear here.

Show 12 quoted lines

>>> 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:
>
> Not at all.
>
> I am saying that "separate history" has no place in git workflow, if these
> multiple roots _originate_ in the same single repository with a working
> tree.

No place in *your* workflow. Oh, wait. Except it has, and you use it in the git tree. So, um... I'm confused.

Show 8 quoted lines

> And all of "git checkout --orphan", "git commit --root" and your
> "git init --root" are solutions to make multiple roots _originate_ in the
> same single repository with a working tree.
>
> I have no trouble in a single repository with multiple roots if that is
> done in a distribution point, which by definition does not need and
> typically does not have any working tree. Options to "checkout/commit"
> would not help as they need a working tree.

I'm not sure where you're going with the "working tree" objection. Are you saying that it's ok to _create_ "separate histories" in a bare repository but wrong to do so in a non-bare one? But surely this means it is ok to _have_ "separate histories" in a non-bare repository, since that is what I will get when I do a simple git-clone of the bare one.

If I understand right, the mechanics of the initial creation is what bothers you. Is that right? If so, we're on the same page here, because it bothers me too. The commit or checkout alternatives seem like two halves of a turd sandwich. Both ends are wrong somehow, and it's because of the state of the working directory in the interim.

If I don't understand you right, ignore the sandwich metaphor and please explain.

> The way to do it is to work in multiple repositories, one for each of
> these roots, and push into a single repository from them.

That's one way to do it.

Show 24 quoted lines

>>> 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.
>
> It is "HEAD pointing at a branch that does not yet exist", but I find it
> strangely attractive ;-)
>
>> 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.
>
> I do not think you would even need --keep-index there (running "git init"
> in an existing repository to see what it does. It does not touch the index
> nor HEAD).

In my imagined extension, the "separate history" action needs a clean index. I guess 'git rm -fr *' will suffice, but I think an in-line switch would be more useful... for this "non-git workflow". :-)

> I am not sure if "--root" is the right name but if "git init --root=work"
> that is run to create (not re-init) a new repository points HEAD at a yet
> to be created 'work' branch instead of 'master', I think it would be a
> reasonable alternative.

That's what I meant.  How about this?

   git init --new-root-branch=<new-branch-name>

> By the way, why did you drop the mailing list?

Clicked the wrong button.  Not used to gmail yet for this.  Sorry about that.

Phil