On 2/20/07, Junio C Hamano <junkio@xxxxxxx> wrote:
"Santi Béjar" <sbejar@xxxxxxxxx> writes:
>> > There are two cases where the behaviour is changed:
>> >
>> > 1) branch.*.merge no longer must exactly match the remote part
>> > of the branch fetched. Both are expanded in full (as refs/heads/...)
>> > and matched afterwards.
> ...
>> I see this as a regression.
>> If you are setting configuration, wouldn't you rather see the
>> behaviour consistent even when remote adds new refs?
Maybe I misread your description, but I took it to mean that you
are allowing:
branch.master.merge = a
to mean what we traditionally spelled
branch.master.merge = refs/heads/a
and guessed (I haven't looked for where it happens in the code)
the way you do that conversion is by tail-matching the ref; if
the other end creates "refs/heads/b/a", suddenly remote branch
b/a starts matching that pattern wouldn't it?
No. branch.master.merge = a is equivalent to refs/heads/a and only
matches with the remote branch refs/heads/a. It continues to exactly
match the two branches, but with the full patch (refs/...). So now it
is possible to have:
[remote "origin"]
url = ...
fetch = refs/heads/*:refs/heads/origin/*
[branch "master"]
remote = origin
merge = master
or the other way:
[remote "origin"]
url = ...
fetch = master:refs/heads/origin
[branch "master"]
remote = origin
merge = refs/heads/master
Earlier we fixed the ambiguous use of branch.*.merge in
756373da; I think the same reasoning should apply here.
Configuration is something you set once because you want to
forget about it afterwards (iow, not having to type every time),
and I think making sure it names things unambiguously outweighs
one-time convenience of being able to write the configuration in
a looser fashion.
It is unambiguous.
But if it is problematic I'll try to keep the current behaviour.
Santi
-
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