Michael Witten <mfwitten@xxxxxxxxx> writes: > 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. -- Matthieu Moy http://www-verimag.imag.fr/~moy/ -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html