Ambiguity warning printed twice ?

Ambiguity warning printed twice ?

[Kaartic Sivaraam]

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?


-- 
Regards,
Kaartic Sivaraam <kaarticsivaraam91196@gmail.com>

Re: Ambiguity warning printed twice ?

[Jeff King]

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

Re: Ambiguity warning printed twice ?

[Kaartic Sivaraam]

On Thu, 2017-06-22 at 10:23 -0400, Jeff King 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".
> 
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!

> 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.
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). :)

-- 
Regards,
Kaartic Sivaraam <kaarticsivaraam91196@gmail.com>