Jeff King <peff@xxxxxxxx> writes: > What does this do: > > git for-each-ref --format='%(refname:remove-standard-prefix)' > > ? > > Is there no standard prefix, because we are not in branch/tag? Does it > remove well-known prefixes like "refs/heads/", "refs/tags/", etc? Does > it remove the first two components (e.g., what happens to > "refs/foo/bar")? If so, what happens to "refs/stash"? I think our mails crossed. I envisioned that the documentation would go something like this: remove-standard-prefix:: When the refname begins with one of the well-known prefixes, the prefix is stripped from it (and when it does not start with any of the well-known prefixes, the refname is left as-is). "refs/heads/", "refs/remotes/" and "refs/tags/" are the well-known prefixes that are removed (as this modifier is primarily meant to allow users emulate the listing modes of "git tag" and "git branch") but this set may change over time (we may teach it to remove "refs/changes/" in later versions of Git, for example). > Yeah, I am definitely on board with trying to do the most minimal thing > for the regression fix and worry about more advanced concerns later (if > at all). It seems to me that "error out" is a pretty minimal behavior, > though, and one that doesn't lock us into any behaviors (i.e., it is > generally OK to take something that did not work at all before, and give > it new useful behavior; it is not OK to change something that did > something useful before). The thing that worried me the most is that "strip=<n>" is a very intuitive and nice notation that end users would want to use it beyond emulating "git tag" literally, and one behaviour we happen to pick, be it "error out" or "leave it intact", would have a high chance of being not the most useful one. If we define it to error out, somebody somewhere will abuse it to "ensure that all branch names are at least two levels deep" or something we do not anticipate now and start relying on the "erroring out" behaviour, and then complain when we later "allow it to do something more useful" that it no longer errors out. Having said all that, I think I can live with "strip=<n>" that happens to pick a single behaviour that we pick with the best knowledge we have right now. If we fear the compatiblity wart so seriously, we can always add a separate "strip-nofail=<n>" variant that gives a different behaviour from "strip=<n>" that errors out. Another useful variant might be "strip <n> levels if we can, otherwise pretend that the ref did not even pass the filtering criteria and do not show anything about the ref on the output", by the way. > So what about this: > > 1. Implement ":strip=<n>" and use it from git-tag. > > 2. Have it error out on a ref with fewer than <n> components. This > should be impossible to trigger via "git-tag" with the default > format. > > 3. Explicitly document that the behavior for values of <n> that are > not positive integers is undefined and subject to change (or > alternatively, we can simply error out). > > > That _is_ user-visible, but it seems like "strip" is a fairly flexible > mechanism by itself (enough that I do not mind living with it forever), > and we haven't made any promises about the ambiguous parts. OK. -- 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