Jeff King <peff@xxxxxxxx> writes: > This is obviously the one that can break existing fetch-pack users. I > doubt they exist. If they do, there are a few alternatives: > > 1. Come up with some more sane rules for path_match (e.g., try full > strings first, use full-string matching for things starting with > "refs/", etc). > > 2. Leave the matching in-place for git-fetch-pack, but use exact > matching for internal users that will always provide qualified refs > (i.e., "git fetch"). I think the latter is the sane thing to do _if_ this becomes an issue, and as you mention, it is in line with what "git fetch" wrapper already does. Given that fetch-pack was meant to be driven by "git fetch" wrapper that turns the command line and other refspecs into full refnames on the remote end before calling it, and also as you mentionied that it is clearly documented as "relative to $GIT_DIR", I do not think we should support the tail-match semantics at all in the first place. -- 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