Nguyễn Thái Ngọc Duy <pclouds@xxxxxxxxx> writes: > This allows you to do "git clone --branch=v1.7.8 git.git" and work > right away from there. No big deal, just one more convenient step, I > think. --branch taking a tag may be confusing though. > > We can still have master in this case instead of detached HEAD, which > may make more sense because we use --branch. I don't care much which > way should be used. You clone a single lineage of the history, either shallowly or fully, either starting at the tip of one single branch or a named tag. What is the expected use scenario of a resulting repository of this new feature? As this is creating a repository, not a tarball extract, you certainly would want the user to build further history in the resulting repository, and it would need a real branch at some point, preferably before any new commit is made. Which makes me think that the only reason we would use a detached HEAD would be because we cannot decide what name to give to that single branch and make it the responsibility of the user to run "git checkout -b $whatever" as the first thing. I think the real cause of the above is because this patch and its previous companion patch conflate the meaning of the "--branch" option with the purpose of specifying which lineage of the history to copy. The option is described to name the local branch that is checked out, instead of using the the same name the remote's primary branch. But these patches abuse the option to name something different at the same time---the endpoint of the single lineage to be copied. These two may often be the same, and use of "clone --branch=master" in such a case would mean that you want to name the local branch of the final checkout to be "master" _and_ the endpoint of the single lineage you are copying is also their "master". But the "tag" extension proposed with this change is different. You are specifying an endpoint of the single lineage with the option that is different from any of the branches at the origin, and because you used the "--branch" option for that purpose, you lost the way to specify the primary thing the option wanted to express: what the name of the resulting checkout should be. Perhaps something like "clone --branch=master --$endpoint=v1.7.8" that says "I want a clone of the repository limited to a single lineage, whose history ends at the commit pointed by the v1.7.8 tag, and name the local checkout my master branch" be more appropriate? Also, the user is likely to want to fetch and integrate from the origin with his own history. How should "git pull" and "git fetch" work in the resulting repository? What should the remote.origin.* look like? -- 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