Daniel Barkalow <barkalow@xxxxxxxxxxxx> writes: > I was actually thinking exclusively of the matching of strings like "HEAD" > or "origin/next" or "master" to refs from the list of available refs. It > seems to me like the push code does a better job of handling the same > sorts of things that get_sha1() handles. > > In particular, the handling of "refs/my/funny/thing" is really wrong: it > gets treated as refs/heads/refs/my/funny/thing. git-parse-remote.sh::canon_refs_list_for_fetch() seems to say otherwise, though. - When unspecified, or explicitly spelled HEAD, take HEAD; - Anything that begins with refs/, use it as is; - Anything that begins with heads/, tags/, remotes/, assume it is a branch, a tag, or a tracking branch; - Otherwise assume a branch; So I suspect refs/my/funny/thing is covered by the second rule. But I do agree "otherwise assume a branch" part has huge room for improvement. Especially... > I think that "origin/next" > should also be assumed to be refs/remotes/origin/next instead of > refs/heads/origin/next, at least if you have refs/remotes/origin/ and not > refs/heads/origin/. ... I think that makes perfect sense -- the code should interpret your example as a request to start using a new tracking branch refs/remotes/origin/next. - 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
