From: Michael Witten <mfwitten@gmail.com>
Date: Wed, 28 Sep 2011 04:37:01 GMT
Subject: Re: [PATCH] Docs: git checkout --orphan: `root commit' and `branch head'
Message-ID: <CAMOZ1Bv3b-EkvCrRYw=_s9SXQw+v9wgQbGab7hsz+Wx+tndhJw@mail.gmail.com>
In-Reply-To: <CAG+J_DxzcuYiffm6XVX-RQSxeMwy4Yi7CdhCdddAN=xRyJ2b5Q@mail.gmail.com>

On Wed, Sep 28, 2011 at 04:04, Jay Soffian <jaysoffian@gmail.com> wrote:
> On Tue, Sep 27, 2011 at 1:25 PM, Junio C Hamano <gitster@pobox.com> wrote:
>> Michael Witten <mfwitten@gmail.com> writes:
>>
>>> It seems like a more logical approach would be instead for "git
>>> commit" to take a "--root" option that would create a new root commit
>>> based on the current index and then point the current branch head to
>>> the new root commit. Thus:
>>>
>>>   $ git checkout -b new_branch old_branch
>>>   $ # Manipulate or not
>>>   $ git commit --root
>>>
>>> That's how people think.
>>
>> This may indeed be an improvement. I suspect that we'd need to think about
>> it a bit more, but it feels right (perhaps introduce this new option,
>> deprecate --orphan from the checkout, and then eventually remove it
>> sometime in 1.8.0 timeframe).
>
> Hrm, create new_branch just so you can immediately clobber its SHA1
> with the new commit that has no parents. That doesn't seem quite
> right.

The point is that users think about 2 things:

  * I need to create a root commit.
  * I need a branch head to point to that root commit,
    and I probably want a new branch head to do that.

My goal is to match the way people think; nobody thinks about the SHA1
when doing this task, and everybody thinks about creating a new branch
head.

More to the point, how is it better that "checkout --orphan" sets up
the working tree and index when the user is just going to obliterate
them or alter them significantly?

> Imagine you use "git commit --root" by accident while on
> master, then you have to dig into your reflog?

What's wrong with, say, "git reset --hard ORIG_HEAD"? (note that
ORIG_HEAD is already something understood by git).

> But it's close. Maybe:
>
> $ git commit --new-root-branch=<name>
>
> Which creates <name> with the index as its sole commit and switches
> you to that branch? That doesn't feel quite right either.

The "git commit" command shouldn't be canoodling the branch layer so intimately.

In fact, that's why I dislike:

  git checkout --orphan <branch_head>

The "--orphan" flag was no doubt added to "git checkout" because of
there already existed:

  git checkout -b <branch_head>

However, that is only available as a convenience (that is, a hack) for:

  git branch <branch_head>
  git checkout <branch_head>

It seems to be an even larger hack that "git checkout" as been given
so much control over setting the stage for not only the creation of a
branch head, but also the nature of the ancestry of the *next* commit.