From: Joey Hess Date: Tue, 3 Nov 2020 02:34:04 +0000 (-0400) Subject: comment X-Git-Tag: archive/raspbian/10.20250416-2+rpi1~1^2~106^2~2 X-Git-Url: https://dgit.raspbian.org/?a=commitdiff_plain;h=664bec4297f6aacd959569c0c648076784454544;p=git-annex.git comment --- diff --git a/doc/todo/--debug-level___40__and__47__or_-c_annex.debug-level__41___+_more_debug_information_from_git-annex/comment_3_ea60112be683188e43b27942667ddd77._comment b/doc/todo/--debug-level___40__and__47__or_-c_annex.debug-level__41___+_more_debug_information_from_git-annex/comment_3_ea60112be683188e43b27942667ddd77._comment new file mode 100644 index 0000000000..a14cdc39ef --- /dev/null +++ b/doc/todo/--debug-level___40__and__47__or_-c_annex.debug-level__41___+_more_debug_information_from_git-annex/comment_3_ea60112be683188e43b27942667ddd77._comment @@ -0,0 +1,39 @@ +[[!comment format=mdwn + username="joey" + subject="""comment 3""" + date="2020-11-03T01:47:26Z" + content=""" +It would be possible to split out of AnnexState a value that is +immutable, and have that part not gated behind a MVar, and so avoid the +MVar lookup overhead, since it would just be part of the Annex Reader +monad. And the debug action in that could just be a noop when it's disabled, +and so be essentially zero overhead. One little problem is that option +parsing (eg for --debug) currently runs in the Annex monad, so too late to +change that immutable value. + +Obviously having debug logging in a place where you just needed debug +logging would have been useful. It does not logically follow that we can +determine such places prior to your needing debug logging, or that we will +need debug logging there later. After all, it seems to have been debugged +now. + +I suppose we can say that anything involving canceling a thread, or closing +a file descriptor connected to a pipe, is fairly delicate and so it makes +sense to wrap and debug log those. (Which were the things needing debug +logging in your case.) But the only information available to display is +"thread N" or "FD N", so it would also need to debug log each thread spawn +and FD open point in order to work out which are interesting. (Or wrap the +values with more information, but that rapidly gets ugly.) + +Anyway, I rarely find myself adding debugM calls when debugging git-annex, +generally just playing with the test case rapidly lets a theory be formed +about what's happening, and then do something to test the theory, and I'm +probably most of the way to a fix or at least understanding the problem. + +The main way the current debug output is useful to me is it often hints at +the proximate location of the problem, because of whatever git command +git-annex ran just before it. It would certianly be useful to have +additional debugM wherever there's a lot of code that does not involve +anything that currently logs.. But I don't know a good way to identify +such stretches of code. +"""]]