Jeff King <peff@xxxxxxxx> writes: > I'm not sure "remove-standard-prefix" doesn't open its own questions. > Like "what are the standard prefixes?". It is easy to define, no? This is invented for the internal use of the listing modes of "tag" and "branch", so the users are welcome to use it if they see fit, but how the prefixes are stripped is defined by the convenience of these commands--the behaviour might even change when these commands are enhanced. > If we are going to go with "remove a prefix", I really don't think > "remove if present" is too complicated a set of semantics (as opposed to > "error out" you mentioned above). > > I do like "strip=<n>" for its simplicity (it's easy to explain), and the > fact that it will probably handle the git-branch case for us. The only > open question is what to do if there are fewer components, but I really > think any of the 4 behaviors I gave earlier would be fine. > > Eric' globbing suggestion is simpler for the error case (as a prefix, it > can be "remove if present"), but I think introducing globbing in general > opens up too many corner cases (e.g., does "*" match "/", is "**" > supported, etc). Yeah, I really do not like any of the "do not error out but assume that the user would not care about the ambiguities" solutions for something we primarily intend to use for internal purposes. I agree that "strip=<n>", "remove-prefix=<glob>", and the friends are good for end-user scripting, but they can come later, outside of the scope of this regression fix, and that is the proper time to debate and decide if it is really ok to assume that the user does not care about ambiguity, or it is prudent to error out. A separate "remove-standard-prefix" that is meant for internal use would allow us to push the fix out without having to decide now. -- 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