2012/1/5 Junio C Hamano <gitster@xxxxxxxxx>: > 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? fetch should behave the same regardless this patch. remote.origin.* looks exactly the same. Branch tracking is not set up so pull works half way. > 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. We can still commit with detached HEAD but I guess it's not recommended. For a quick, throwaway repository, it's probably OK. > 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? Branch naming is a local thing. Maybe we could get away with always name it "master" if fetched from a tag. Branch tracking is not set up in this case, so if they want to follow up with upstream, they have to do some more themselves (including renaming "master" to something else for less confusion with upstream "master"). New option is not easily discovered, while "git branch -r master foo" is quite easy. -- Duy -- 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