On Sun, 24 Jun 2007, Junio C Hamano wrote: > Daniel Barkalow <barkalow@xxxxxxxxxxxx> writes: > > > Is this difference simply due to the different languages the matching > > portions of these were originally written in? > > If anything, the semantics on the fetch side is _very_ much > intentional and is done deliberately that way to be usable. > > On the other hand, push started as "matching only", and then > "match tail part of the name" as an afterthought. It was so > afterthought that it had an idiotic behaviour of independently > match the source and destination side even when there is no > colon, which was fixed only recently. > > So if you would want to match fetch and push, you should not > change the semantics on fetch to match what push does, as the > latter was done pretty much without design. > > Having said that, I think fetch and push DWIMmery are > fundamentally different, especially when you do not have a > colon. push without storing anything on the receiving end would > not make any sense whatsoever, but fetch without using tracking > branches does make perfect sense, so push does pretend dst side > has what matched with src side pattern, while fetch treats no > colon pattern as not storing. IOW, even if we wanted to reuse > the code on both sides as much as possible, I suspect we would > need to have details different between them. The no-colon handling is right as it is, as well as the semantics of fetching without tracking refs. 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. 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/. -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
