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

From: Junio C Hamano <junkio@cox.net>
Date: Feb 19, 2007, 23:27 UTC
Message-ID: <7vfy91684y.fsf@assigned-by-dhcp.cox.net>
In-Reply-To: <8aa486160702191413p10c8ca0ek949580ffe953ea79@mail.gmail.com>

"Santi Béjar" <sbejar@gmail.com> writes:

Show 9 quoted lines

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

If somebody does "git checkout -B origin/next" which does:

	git checkout -b next origin/next &&
        git repo-config branch.next.merge $merge

I would expect that the enhanced "checkout" script would not have any trouble arranging $merge to fully spell out refs/heads/next.

Show 7 quoted lines

>> Merging this at this moment would be a pain even if there were
>> no downsides, as there are a few topics that want to touch
>> parse-remote and fetch (two already in 'pu', and git-bundle
>> series also wants to hook into git-fetch); these topics would
>> need to get adjusted if this clean-up goes in first.
>
> A problematic decision :)

Not at all.