On Fri, 16 Jun 2006, Goo GGooo wrote: > > That's confusing - I believed all protocols should behave the same way...? Not really. The primary protocol is the native git one, and the others try to do a best effort, but the http protocol really can't do a very good job unless the server side has run "git update-server-info" to help the http client along. I suspect that the -mm git tree simply doesn't do that. In fact, even the main tree didn't use to do it, but I finally just broke down and added the proper hook to make it always do it automatically when I push. (In case Andrew wants to do that, the way to do it is: echo -e "#!/bin/sh\nexec git-update-server-info" > hooks/post-update chmod +x hooks/post-update inside the git repository - all it will do is always execute that script, and this "git-update-server-info", after you've updated the repo). Finally, the rsync protocol just copies all objects over, and since it doesn't even know _which_ objects it is getting, it doesn't do the normal tag following that the native git protocol does. So to recap: - http is fundamentally weaker, and needs some server-side help to work - rsync is fine for the initial clone, but doesn't actually know what it's doing, so the end result can actually even be a corrupted repository, because you happened to rsync just as it was updating. - the native git protocol generally should be considered the golden standard, where the other ones are just fallbacks in case of problems (like firewalls that don't let git:// through, or more commonly hosted servers that don't do the git protocol at all). Which hopefully clarifies the issue a bit. Linus - To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.htmlReceived on Fri Jun 16 12:47:02 2006
This archive was generated by hypermail 2.1.8 : 2006-06-16 12:47:24 EST