Bert Wesarg <bert.wesarg@xxxxxxxxxxxxxx> wrote: > > given these two refs: > > refs/heads/xyzzy > refs/tags/xyzzy > > first try to shorten "refs/heads/xyzzy": > > first (from the end) matched pattern is "refs/heads/%.*s" with > "xyzzy" as result > > but resolved ref for "xyzzy" is "refs/tags/xyzzy" => continue > > next matched pattern is "%.*s" with "refs/heads/xyzzy" as result > > end result is therefore: "refs/heads/xyzzy" > > second try to shorten "refs/tags/xyzzy": > > first (from the end) matched pattern is "refs/tags/%.*s" with > "xyzzy" as result > > resolved ref for "xyzzy" is "refs/tags/xyzzy" => end > > end result is therefore: "xyzzy" > > the output would be: > > refs/heads/xyzzy > xyzzy > > The question is now, if this is usable for bash completion? Current > bash completion would handle this case wrong, because you get two > xyzzy. I think this is reasonable. Its better than what we have today, which is ambiguous completion. So this looks reasoanble to me. Usually people don't have ambiguous names, but it happens. I've been known to do something stupid like this: git checkout -b v1.0 v1.0 git reset --hard v1.2 git log v1.0 # wtf?!?!!?! ;-) -- Shawn. -- 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
