Jacob Keller <[email protected]> writes: > +remote.<name>.arbitrarypattern:: > + When set to true, fetching from this remote will allow arbitrary complex > + patterns for the fetch refspecs. For example, > + refs/tags/prefix-*:refs/tags/prefix-* will work as expected. Care > should be > + taken as you could fetch refs into names that don't exist on the remote > and > + may end up pushing them again later by accident.
Bad name and explanation, unless you truly mean "arbitrary", like taking something like "refs/ta*/prefix-*-*-foo:refs/*". More importantly, this is not "pattern"; you are talking about refspec, I think. But that probably does not matter. I do not think this even needs to exist as an option. People's existing settings would not have anything other than an asterisk as a whole path component on each side (or no asterisk anywhere), and if they had an asterisk anywhere else they would have gotten an error and wouldn't have made any progress until they fixed it. So if you loosen the current rule sligntly and tell them "If your refspec has an asterisk in it, then you must have one asterisk on each side of it. That rule hasn't changed. But your asterisks no longer have to be a whole path component", such a change would not hurt them. Their existing setting that work would not notice, and existing users would not be relying on a refspec with an asterisk as part of a path component to error out. -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to [email protected] More majordomo info at http://vger.kernel.org/majordomo-info.html
