Re: Ambiguity warning printed twice ?

From: Jeff King <peff@peff.net>
Date: Jun 22, 2017, 14:23 UTC
Message-ID: <20170622142348.hwlrajujgrxo6nwf@sigill.intra.peff.net>
In-Reply-To: <1498135581.2089.1.camel@gmail.com>

On Thu, Jun 22, 2017 at 06:16:21PM +0530, Kaartic Sivaraam wrote:

Show 18 quoted lines

> I accidentally noticed a weird behaviour of 'git status'. In a
> repository I created a branch with the name 'HEAD' by chance. When I
> run 'git status' in the repository it prints a warning about an
> ambiguous reference about 'HEAD' which is expected but it prints it
> twice which seems suspicious.
> 
>     $ git branch
>       HEAD
>       master
>     * test
> 
>     $ git status
>     warning: refname 'HEAD' is ambiguous.
>     warning: refname 'HEAD' is ambiguous.
>     On branch test
>     ....
> 
> Any reasons behind this behaviour or is this a bug?

It's not unreasonable for a complex command like git-status to need to resolve HEAD multiple times. You can see how we get to each case by running:

  gdb /path/to/git-status

and then doing:

  break warning
  run

Each time it breaks, you can run "bt" to get a backtrace, and then "c" to continue".

It looks like the first one is when cmd_status() resolves the HEAD to see if we are on an unborn branch, and the second is done by wt_status to diff the index against HEAD. It would probably be possible to feed the results of the first resolution to wt-status. But that would just help this case, and I wouldn't be surprised if there are other commands that do multiple resolutions (or even scripts which call multiple commands).

Since warning should be rare, we could keep track of which names we've warned about and suppress multiple warnings. That would help single-process cases like this, but scripts which call multiple Git commands would still show multiple warnings. I don't know if that's worth doing or not.

-Peff