On Wednesday 2006 November 22 12:56, Junio C Hamano wrote: > > However, git-ls-remote needs the name of the remote repository (of > > course), but that isn't directly available in git-parse-remote.sh. > > Is it really the case? I do not remember the details offhand, > but I do not think canon_refs_list_for_fetch is the function you > should be messing with to implement the remote."origin".fetch > stuff. It should be get_remote_default_refs_for_fetch(). The > function returns the list based on which remote, so it surely > knows which remote the caller is talking about. The problem is that canon_refs_list_for_fetch bombs out too early because "*" is not an acceptable name for a ref. > However, I would recommend against actually running ls-remote to > help "git-fetch" inside git-parse-remote.sh. I think you should > run ls-remote upfront early in git-fetch because there are at > least two other parts in git-fetch that wants the same ls-remote > output: Okay. That's what I'll do. It means altering git-check-ref-format to prevent the early bomb out. Perhaps I should move this check to somewhere after I've done the reflist expansion? > (1) dumb protocols currently cannot deal with a remote that has I'm not sure I've understood this point. I shall look at git-fetch.sh more closely to try and address this though. > (2) when doing a fetch with tracking branches (which is what Accepted. Andy -- Dr Andy Parkins, M Eng (hons), MIEE andyparkins@xxxxxxxxx - 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