Re: [PATCH/RFC 2/3] git-fetch: Split fetch and merge logic

> "Santi Béjar" <sbejar@gmail.com> 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?

>
> 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.