Re: Ambiguity warning printed twice ?

[Jeff King <peff@peff.net>]

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

> 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