On Thu, Sep 29, 2011 at 21:50, Phil Hord <phil.hord@xxxxxxxxx> wrote: > On Thu, Sep 29, 2011 at 5:28 PM, Michael Witten <mfwitten@xxxxxxxxx> wrote: >> On Thu, Sep 29, 2011 at 21:02, Phil Hord <phil.hord@xxxxxxxxx> wrote: >>> 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. >> >> That would be a good place for the "git checkout --no-parent" variant, >> especially given that I think "git checkout --no-parent" should produce >> an empty working tree and index, which we can all note is essentially >> what "git init" gives us. >> >> Your suggestion seems like a corroboration of my stance. > > I'm not arguing the functionality; just the command spelling. > Consider your stance corroborated. > > I don't like "git checkout" for this because > 1. git-checkout is too popular already; oddball functions like this > should live in the shadows. > 2. git-checkout is conceptually wrong, imho. git-checkout means > "fetch me this commit" or "fetch me files from this commit". > Technically it does the same thing that we're talking about here (it > frobs the index, the workdir and HEAD), but conceptually it is very > different. > > Conceptually, I think the functionality you're talking about is more > akin to git-init. Actually, I'd say that the purpose of "git checkout" is to set the working tree and index; in that sense, "git init" could in fact be implemented by using "git checkout". The key to what I'm saying, though, is that 2 scenarios are involved: * Make a root starting with nothing. * Make a root based off something. The user should be able to express that, so that commands like "git status" make sense. Currently, the user is only able to express the first scenario: * Make a root starting with nothing. but existing stuff is automatically added in case the user wants to do the second scenario, but that makes "git status" essentially unusuable for the second scenario, anyway. -- 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