Daniel Barkalow [off-list ref] 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?
On Sat, 16 Jun 2007, Junio C Hamano wrote:
Daniel Barkalow [off-list ref] writes:
quoted
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).
Actually, with my current code it's a simplification to have the code
expand all shortcuts up front and do all of the matching on explicit
names. I'm trying to use "struct ref" for fetching, and it doesn't work if
you have to store both the name that would match a "merge" setting and the
name that would match the actual remote ref.
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?
I'd personally be in favor of requiring the config file to be explicit
everywhere, for just this reason, but we've got tests, if not
documentation (and I haven't checked documentation on this one) saying
that shortcuts work in config files.
This is, this is supported, and marks refs/heads/two for merge:
[remote "config-glob"]
fetch = refs/heads/one:refs/remotes/rem/one
fetch = 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
But I'd prefer to by able to discard the information of whether a short
form was used early.
-Daniel
*This .sig left intentionally blank*