Thread (11 messages) 11 messages, 7 authors, 2016-06-15

Re: [PATCH] Docs: git checkout --orphan: `root commit' and `branch head'

flat view

From: Michael Witten <hidden>
Date: 2016-06-15 22:52:07

On Wed, Sep 28, 2011 at 04:04, Jay Soffian [off-list ref] wrote:
On Tue, Sep 27, 2011 at 1:25 PM, Junio C Hamano [off-list ref] wrote:
quoted
Michael Witten [off-list ref] writes:
quoted
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.
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help