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

On Wed, Sep 28, 2011 at 14:09, Matthieu Moy
[off-list ref] wrote:

Michael Witten [off-list ref] writes:

quoted

Well, as Junio mentioned, "--orphan" could be deprecated in favor of
"--no-parent"; the uncommon nature of this task works to our
advantage, in that it makes a deprecation of "--orphan" easy.

I agree that _some_ cases would be more natural with commit --no-parent,
but I disagree that it is a better solution in general.

For example

# I want to create a new root commit with a different tree
git rm -fr *
vi file-in-new-project.txt
git add file-in-new-project.txt
# continue hacking for a while
git commit -m "New project" # oops, I forgot the --no-parent

History is not destroyed and you can still "git reset" back to the
previous commit, but you've at least temporarily damaged your branch
(and no --force flag could have prevented it). With "git checkout
--orphan" in the above scenario, you run the command at the time you
take the decision you want to create a root commit, and then hack
normally.

Even if you use it normally:

# I want to create a new root commit with a different tree
git checkout -b new-project
# hack for a while
git status
# ?!? why are files shown as 'deleted', 'moved', 'modified', I said I
# was creating a new project!

Also, with your proposal, we would need to add two flags to "commit"
(--no-parent and --force), which is one of the first command beginners
learn, while in the current state we have just one for "checkout" to do
the trick, and newbies do not use or read the doc for checkout, so it's
not scary for them.

Well, those are mildly interesting scenarios. I can only say that I don't
think we should cater to people who either have amnesia or work casually
on a repository for short bursts every few months or so.