{"thread":{"id":"8621","subject":"config-glob-octopus","startedAt":"2007-06-17T01:02:25Z","lastAt":"2007-06-17T03:28:49Z","messageCount":3,"participants":["Daniel Barkalow","Junio C Hamano"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"45199","messageId":"Pine.LNX.4.64.0706162039530.4740@iabervon.org","threadId":"8621","inReplyTo":null,"subject":"config-glob-octopus","fromName":"Daniel Barkalow","fromEmail":"barkalow@iabervon.org","sentAt":"2007-06-17T01:02:25Z","receivedAt":"2007-06-17T01:02:25Z","isPatch":false,"sender":{"key":"barkalow@iabervon.org","avatar":"https://avatars.githubusercontent.com/u/55364219?v=4"},"body":"With this configuration:\n\n[remote \"config-glob\"]\n\tfetch = refs/heads/one:refs/remotes/rem/one\n\tfetch = refs/heads/two:refs/remotes/rem/two\n\tfetch = refs/heads/three:refs/remotes/rem/three\n[branch \"br-config-glob-octopus\"]\n\tremote = config-glob\n\tmerge = refs/heads/one\n\tmerge = two\n\tmerge = remotes/rem/three\n\nIt seems to me like \"two\" should be marked for merge, since \"two\" \ncanonicalizes to \"refs/heads/two\", which matches the pattern and is \nfetched. However, current git-fetch marks it not-for-merge, and the test \ndemands this.\n\nShouldn't the value of \"merge\" permit the same shortcuts that the lhs of \n\"fetch\" permits, even if the matching fetch line isn't using them in this \ncase? (And vice versa, for a canonical value of merge when the fetch is a \nshortcut)\n\n\t-Daniel\n*This .sig left intentionally blank*\n"},{"id":"45200","messageId":"7vtzt71hks.fsf@assigned-by-dhcp.pobox.com","threadId":"8621","inReplyTo":"Pine.LNX.4.64.0706162039530.4740@iabervon.org","subject":"Re: config-glob-octopus","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2007-06-17T01:43:31Z","receivedAt":"2007-06-17T01:43:31Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Daniel Barkalow writes:\n\n> With this configuration:\n>\n> [remote \"config-glob\"]\n> \tfetch = refs/heads/one:refs/remotes/rem/one\n> \tfetch = refs/heads/two:refs/remotes/rem/two\n> \tfetch = refs/heads/three:refs/remotes/rem/three\n> [branch \"br-config-glob-octopus\"]\n> \tremote = config-glob\n> \tmerge = refs/heads/one\n> \tmerge = two\n> \tmerge = remotes/rem/three\n>\n> It seems to me like \"two\" should be marked for merge, since \"two\" \n> canonicalizes to \"refs/heads/two\", which matches the pattern and is \n> fetched. However, current git-fetch marks it not-for-merge, and the test \n> demands this.\n>\n> Shouldn't the value of \"merge\" permit the same shortcuts that the lhs of \n> \"fetch\" permits, even if the matching fetch line isn't using them in this \n> case? (And vice versa, for a canonical value of merge when the fetch is a \n> shortcut)\n\nI do not see much reason for that kind of complication.\nHonestly speaking, I do not like the fallback that we use for\nthe third one (using the remote tracking name).\n\nWhen you are righting down your configuration file, you are\ndoing so to reuse that entry over and over, so why not be\nexplicit for once and not worry about cases where the remote\nadds ambiguous 'two' that is not refs/heads/two?\n"},{"id":"45202","messageId":"Pine.LNX.4.64.0706162321060.4740@iabervon.org","threadId":"8621","inReplyTo":"7vtzt71hks.fsf@assigned-by-dhcp.pobox.com","subject":"Re: config-glob-octopus","fromName":"Daniel Barkalow","fromEmail":"barkalow@iabervon.org","sentAt":"2007-06-17T03:28:49Z","receivedAt":"2007-06-17T03:28:49Z","isPatch":false,"sender":{"key":"barkalow@iabervon.org","avatar":"https://avatars.githubusercontent.com/u/55364219?v=4"},"body":"On Sat, 16 Jun 2007, Junio C Hamano wrote:\n\n> Daniel Barkalow writes:\n> \n> > With this configuration:\n> >\n> > [remote \"config-glob\"]\n> > \tfetch = refs/heads/one:refs/remotes/rem/one\n> > \tfetch = refs/heads/two:refs/remotes/rem/two\n> > \tfetch = refs/heads/three:refs/remotes/rem/three\n> > [branch \"br-config-glob-octopus\"]\n> > \tremote = config-glob\n> > \tmerge = refs/heads/one\n> > \tmerge = two\n> > \tmerge = remotes/rem/three\n> >\n> > It seems to me like \"two\" should be marked for merge, since \"two\" \n> > canonicalizes to \"refs/heads/two\", which matches the pattern and is \n> > fetched. However, current git-fetch marks it not-for-merge, and the test \n> > demands this.\n> >\n> > Shouldn't the value of \"merge\" permit the same shortcuts that the lhs of \n> > \"fetch\" permits, even if the matching fetch line isn't using them in this \n> > case? (And vice versa, for a canonical value of merge when the fetch is a \n> > shortcut)\n> \n> I do not see much reason for that kind of complication.\n> Honestly speaking, I do not like the fallback that we use for\n> the third one (using the remote tracking name).\n\nActually, with my current code it's a simplification to have the code \nexpand all shortcuts up front and do all of the matching on explicit \nnames. I'm trying to use \"struct ref\" for fetching, and it doesn't work if \nyou have to store both the name that would match a \"merge\" setting and the \nname that would match the actual remote ref.\n\n> When you are righting down your configuration file, you are\n> doing so to reuse that entry over and over, so why not be\n> explicit for once and not worry about cases where the remote\n> adds ambiguous 'two' that is not refs/heads/two?\n\nI'd personally be in favor of requiring the config file to be explicit \neverywhere, for just this reason, but we've got tests, if not \ndocumentation (and I haven't checked documentation on this one) saying \nthat shortcuts work in config files.\n\nThis is, this is supported, and marks refs/heads/two for merge:\n\n[remote \"config-glob\"]\n\tfetch = refs/heads/one:refs/remotes/rem/one\n\tfetch = two:refs/remotes/rem/two\n\tfetch = refs/heads/three:refs/remotes/rem/three\n[branch \"br-config-glob-octopus\"]\n\tremote = config-glob\n\tmerge = refs/heads/one\n\tmerge = two\n\tmerge = remotes/rem/three\n\nBut I'd prefer to by able to discard the information of whether a short \nform was used early.\n\n\t-Daniel\n*This .sig left intentionally blank*\n"}]}