> Junio C Hamano <gitster@xxxxxxxxx> writes: > > > Emily Shaffer <emilyshaffer@xxxxxxxxxx> writes: > > > >> The main concern I saw here was "we are doing a lot of work that isn't > >> used if the user doesn't want to log traces" - should I approach a > >> reroll of this topic by trying to be smarter about whether to set > >> 'quiet' or 'print' or 'verbose' or whatever it is renamed to, based on > >> whether there is a trace destination? Then for systems which are logging > >> traces the extra work is worth it, but for everyone else it can function > >> as before. > >> > >> I don't love it from a design perspective - it feels a little like > >> progress module is looking a little too closely at trace module > >> internals. > > > > Isn't that primarily due to the decision to tie progress and trace > > too closely? If so, perhaps that needs to be revisited? > > Or the "too close coupling" needs to be accepted as the cost of > doing so (as "progress is often a good cue for an event worth > tracing" was a convenient way to cheat by programmers not to spend > too many braincycles to decide adding trace points---they > automatically got them when they decided to show progress output). I wouldn't describe it as "cheat", but I agree with the general sentiment - in general, I would think that if something is lengthy enough to need to indicate progress to the user, we should trace its performance.
