Junio C Hamano <gitster@xxxxxxxxx> writes: > Phil Hord <phil.hord@xxxxxxxxx> writes: > >> 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. > > Hmm, this does not feel very natural to me; unless "git init --root=work" > uses 'work' branch instead of 'master' when creating a new repository, > that is. But it is attractive that init is much less often used than > checkout/commit and everybody knows it is somewhat a _special_ operation. > >>> That leaves "Hidden History" the only useful use case. IOW, the answer to >>> the first question above is not "Separate or Hidden History", but is >>> "Hidden History and nothing else". >> >> I think you're saying that the "hidden history" scenario is more >> special than the "separate history" one because of these reasons: > > Not at all. > > I am saying that "separate history" has no place in git workflow, if these > multiple roots _originate_ in the same single repository with a working > tree. And all of "git checkout --orphan", "git commit --root" and your > "git init --root" are solutions to make multiple roots _originate_ in the > same single repository with a working tree. > > I have no trouble in a single repository with multiple roots if that is > done in a distribution point, which by definition does not need and > typically does not have any working tree. Options to "checkout/commit" > would not help as they need a working tree. > > The way to do it is to work in multiple repositories, one for each of > these roots, and push into a single repository from them. > >>> And a half of the the answer to the second question is "checkout --orphan" >>> (and the other half would be "filter-branch"). "checkout --orphan" does >>> have major safety advantage than introducing "commit --no-parent", as Peff >>> pointed out earlier (to which I agreed). >> >> The thing I don't understand about "checkout --orphan" is exactly what >> you're getting when you do this. I assume you get a populated index >> and a non-existent HEAD. This seems a lot like "git init" to me, >> especially in the non-existent HEAD area. > > It is "HEAD pointing at a branch that does not yet exist", but I find it > strangely attractive ;-) > >> I didn't think git init would be much use for this scenario before, >> but now I've changed my mind. >> >> git init --root=<newbranch> --keep-index >> >> Again, this avoids complicating the common commands. But maybe it >> does overload init with extra baggage. > > I do not think you would even need --keep-index there (running "git init" > in an existing repository to see what it does. It does not touch the index > nor HEAD). > > I am not sure if "--root" is the right name but if "git init --root=work" > that is run to create (not re-init) a new repository points HEAD at a yet > to be created 'work' branch instead of 'master', I think it would be a > reasonable alternative. > > By the way, why did you drop the mailing list? -- 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