On Wed, Oct 12, 2011 at 12:20:18PM -0700, Junio C Hamano wrote: > Jeff King <peff@xxxxxxxx> writes: > > > We also look at ref_rev_parse_rules in shorten_unambiguous_ref. So even > > with your patch, I still get the warning with: > > > > $ git branch config > > $ git for-each-ref --format='%(refname:short)' refs/heads/ > > > > It looks like we also use it in remote.c:count_refspec_match, but I > > haven't figured out if that can trigger a warning or not. > > I do not think this is "do not trigger a warning" exercise. This is "we no > longer consider names outside refs/ as potential magic refs unless they > are all uppercase". > > If the updated dwim_ref() says $GIT_DIR/frotz will no longer create > ambiguity with $GIT_DIR/refs/heads/frotz, then refname_match() needs to > know about it, and cause count_refspec_match() to say that "frotz" > uniquely names "refs/heads/frotz". > > The same stands for shorten_unambiguous_ref(). If $GIT_DIR/frotz no longer > is ambiguous with $GIT_DIR/refs/heads/frotz, then %(refname:shrot) for > refs/heads/frotz should yield "frotz", and we should not have to qualify > it as "heads/frotz". Absolutely. I was lazy in how I woreded it, but I meant that the warning was the indicator that we were doing something buggy, not that it was the bug itself. It just happened to be a convenient way to test. :) Your most recent patch looks right. -Peff -- 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