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) -Daniel *This .sig left intentionally blank* - 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
