Daniel Barkalow [off-list ref] 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.
On Sun, 24 Jun 2007, Junio C Hamano wrote:
Daniel Barkalow [off-list ref] writes:
quoted
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*