Johannes Schindelin <Johannes.Schindelin@xxxxxx> writes: > Oh? Well, to me, "clone" meant something like the genetics thing, i.e. get > a copy of the repository. Since a "branch" is not the complete repository, > but only part of it, I would have expected "engraft" instead of "clone" > there. > > But I can learn! So (post-1.5.0, maybe?) I'd be perfectly d'accord with > something like this > > git clone git://.../git.git#html > > to mean "just fetch the branch html, and check it out". I agree that the word "clone" to me sounds like "copy the whole repo", so a single branch cloning feels it is something different from "clone", but I do not think it means wholeness must be the only mode of operation. Except that I do not particularly think the URL fragment notation is such a "cool" syntax. >> I think the logic to decide where to point remotes/$origin/HEAD to >> should be moved to "git-remote add -m" when we eventually rewrite >> "git-clone" to use "git-remote add -f". And while we would do so, we >> can make a trivial extension to fetch-pack protocol to carry the HEAD >> symref information. All will be good once that happens. > > Would you like this as a multi_ack-like extension? > > But then how to teach the dumb protocols in a backwards-compatible > fashion? I am not talking about enhancing ls-remote output nor info/refs file format. I do not think we need to do anything special to support it in backwards compatible way. Look at what dumb protocols do in git-clone. http already knows where HEAD points at when it fetches HEAD with curl. I do not particularly care about rsync, but I suspect it can be handled the same way. - 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