Ambiguity warning printed twice ?

Happy day everyone,

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?

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

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

On Thu, 2017-06-22 at 10:23 -0400, Jeff King wrote:

Thanks for the guidance about debugging. It was very helpful and was a reminder that there's a useful tool called the debugger which I have failed to consider!

I guess it's NOT. If I understood things correctly, this issue occurs only if the ref 'HEAD' is ambiguous. Trying out a very approximate calculation shows the probability to be some where around "1 in the trillions or quadrillions". Further, it drops down to 0 when common sense is kicked-in (most people would know git uses HEAD internally). Thus this isn't worth enough to deserve a fix except if there are other things that I'm missing that could spoil my calculation.

Anyways, hoping some "big" would happen, that avoids these kind of issues (inherently). :)