Re: [PATCH] git-completion.bash: always swallow error output of for-each-ref

From: Jeff King <peff@peff.net>
Date: Feb 4, 2016, 11:45 UTC
Message-ID: <20160204114506.GA1710@sigill.intra.peff.net>
In-Reply-To: <alpine.DEB.2.20.1602041216240.2964@virtualbox>

On Thu, Feb 04, 2016 at 12:26:19PM +0100, Johannes Schindelin wrote:

Show 7 quoted lines

> > Hmm. I feel like this case (HEAD points to a branch, then `fetch
> > --prune` deletes it) came up recently and we discussed quieting that
> > warning. But now I cannot seem to find it.
> 
> I am pretty certain that it came up in my patch series:
> 
> 	http://thread.gmane.org/gmane.comp.version-control.git/278538

Good, I'm not going crazy! But my search skills are apparently atrophying. :)

It looks like we just addressed the git-gc issue there. for-each-ref uses the "rawref" interface, so it gets fed broken things and warns about them.

I'm tempted to say that it should just silently ignore broken symrefs, as they're kind-of a normal thing. But I also think Sebastian's patch to squelch stderr during completion is quite reasonable, too.

> This is funny: after reading the commit message at
> https://github.com/git/git/commit/0571979b it eludes me why strip=2 should
> be so much faster than short...

:short is slow because it checks for ambiguity. So it has to walk the dwim_ref() rules backwards, checking if each possibility is an existing ref.

Whereas strip=2 is literally just skipping past the early bits of the refname string.

-Peff