Re: config-glob-octopus

[Junio C Hamano <gitster@pobox.com>]

Daniel Barkalow <barkalow@iabervon.org> writes:

> With this configuration:
>
> [remote "config-glob"]
> 	fetch = refs/heads/one:refs/remotes/rem/one
> 	fetch = refs/heads/two:refs/remotes/rem/two
> 	fetch = refs/heads/three:refs/remotes/rem/three
> [branch "br-config-glob-octopus"]
> 	remote = config-glob
> 	merge = refs/heads/one
> 	merge = two
> 	merge = remotes/rem/three
>
> It seems to me like "two" should be marked for merge, since "two" 
> canonicalizes to "refs/heads/two", which matches the pattern and is 
> fetched. However, current git-fetch marks it not-for-merge, and the test 
> demands this.
>
> Shouldn't the value of "merge" permit the same shortcuts that the lhs of 
> "fetch" permits, even if the matching fetch line isn't using them in this 
> case? (And vice versa, for a canonical value of merge when the fetch is a 
> shortcut)

I do not see much reason for that kind of complication.
Honestly speaking, I do not like the fallback that we use for
the third one (using the remote tracking name).

When you are righting down your configuration file, you are
doing so to reuse that entry over and over, so why not be
explicit for once and not worry about cases where the remote
adds ambiguous 'two' that is not refs/heads/two?