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@xxxxxxxxx>
