On Sun, 24 Jun 2007, Junio C Hamano wrote: > 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. Ah, okay. I think a few bits got lost somewhat in Julian's translation to C. I agree with the first three rules there, and with the last rule being the last rule, and sticking more things in between those sets is easy enough. > 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. Currently, it doesn't even notice if you've got the tracking branch already. Should it have some rule to prefer things that exist over things that don't? When refs/remotes/origin/next doesn't exist, should it require that refs/remotes/origin/ already exist? In any case, the big question is whether the push code should use these rules, too, for the corresponding portions, in which case I can share the code (and, for that matter, the documentation, which would be even nicer, because we've currently got a lot of hints about refspecs in different places but nothing complete anywhere). -Daniel *This .sig left intentionally blank* - 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
