Re: Ambiguity warning printed twice ?

[Kaartic Sivaraam <kaarticsivaraam91196@gmail.com>]

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>