I've got an annoying repository where all of the branches upstream[*] have names, for a project "my-proj" like: some/constant/stuff/$VERSION/junk/my-proj I'd like to be able to use refspecs like: fetch = some/constant/stuff/*/junk/my-proj:refs/remotes/origin/* I've written an implementation (which mainly involved having only one place do the matching and replacement for pattern refspecs, and then making that one place a little more clever), so that's not hard. But we currently prohibit refspecs like this, and I think we may want to prohibit some patterns of this general form, in order to keep typos from doing surprising things. My use case is actually, more precisely: some/constant/stuff/$PROJ-$NUMBER/junk/my-proj Where $NUMBER is the version number, and $PROJ is usually, but not quite always "my-proj"; the exception being that it might be effectively a superproject. So I'd like to have: fetch = some/constant/stuff/my-proj-*/junk/my-proj:refs/remotes/origin/* But I can live with remote branches like "my-proj-2.4" instead of "2.4". I think it would make sense, and limit typo damage, to say that the * can only expand to something with a '/' in it if the star has a slash or the end of the string on each side. What are other people's thoughts? Should I have a config option for how flexible matching is permitted? Any particular constraints I should have in general? [*] (This is actually a Perforce upstream, but I want to keep the mapping from Perforce into git simple and not grow another pattern-matching format, so I'm just copying Perforce paths as ref names, and then I want the match them with the usual code) -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
