Jakub Narebski <jnareb@xxxxxxxxx> writes: >> I did not find anything MS'esque in what MST did in his patch, >> though. I think it is a reasonable thing to ask for from a >> clone. For example, if you are coming from CVS or have used >> Cogito, cloning a single branch is not an unusual operation at >> all. > > But when we clone whole repository we could have download whole > object database of cloned repo as-is (perhaps packing loose objects > in smart/git-aware transports). I think your point is if you have branches A and B, cloning A+B as a whole is a lot less expensive than cloning A and then B separately. While that is true, I do not think that reasoning would apply to somebody, especially behind a slow link, who is only interested in A. She does not want to pay the cost of A+B, when she only wants A, even if A+B is much less expensive than twice the cost of getting A. Also, if she later gets interested in B, git fetch will make the "what's common" optimization. It won't be like cloning A and then fetching B into the same repository later would be twice as expensive compared to the case where you start from a clone as a whole. The overall transfer cost would probably be comparable. > By the way, there was discussed idea about marking pu-like branches > as being rewound (non-fast forwarding) in the config file, and somehow > transferring this information for git-clone for it to have '+' for > some refspecs. What happened to that idea? Was it abandoned... Well, I would not call some idle talk without a concrete design (preferably with a proof-of-concept code, but that is not an absolute requirement) "idea". Something that did not even start cannot get abandoned ;-). I thought that it would not hurt to have something like that, but because in 1.5.0 "git clone" creates fetch configuration of 'forcing' kind by default, I do not think it makes that much of a difference. - 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