From: Tuncer Ayaz Date: Fri, 07 Nov 2008 03:26:09 GMT Subject: Re: [PATCH] Teach/Fix pull/fetch -q/-v options Message-ID: <4ac8254d0811061926m32183c2fx69ec5b5f4559e608@mail.gmail.com> In-Reply-To: <4ac8254d0811011023r10a4ce45ka962344ceef564f0@mail.gmail.com> On Sat, Nov 1, 2008 at 6:23 PM, Tuncer Ayaz wrote: > On Tue, Oct 28, 2008 at 4:21 AM, Junio C Hamano wrote: >> Nanako Shiraishi writes: >> >>> Quoting Tuncer Ayaz : >>> >>>> After fixing clone -q I noticed that pull -q does not do what >>>> it's supposed to do and implemented --quiet/--verbose by >>>> adding it to builtin-merge and fixing two places in builtin-fetch. >>> >>> Junio, may I ask what the status of this patch is? Maybe the patch was >>> lost in the noise? The commit log message is written very differently from >>> existing commits in the history of git, and I am thinking that maybe that is >>> why you did not like the whole patch? Or is it lack of any test script? >> >> Well, perhaps you've been with us long enough to get too picky like >> myself, but this was genuinely lost in the noise and my scrambling to get >> back to normal. We do not typically say "I did this, I did that", but the >> first paragraph in Tuncer's message is perfectly fine. I would probably >> liked the second paragraph better if it were after --- lines (it is more >> about the possible enhancements in other areas, and does not belong to the >> commit log message for this change), but it is not a grave enough offence >> to get the patch rejected. > > Should I resend the patch with a short and simple commit message > like the following? > --8<-- > Implement git-pull --quiet and --verbose by adding the > options to git-pull and fixing verbosity handling in git-fetch. > -->8-- > >> The patch itself looks Ok; the lack of test script additions does indeed >> bother me somewhat, but it is not too big a deal. > > I took a look at t/ and am not quite sure whether I should test -v/-q > by analyzing stdout output's length & content. > > I think testing -q and -v makes more sense on a global and not > git-pull or git-fetch level. For that to be possible I envision building > common verbosity-based logging functions/macros. > > I don't like the idea of scanning stdout for length or content as > long as we're not sure that all errors and warnings are sent > to stderr and stdout is for info and verbose only. > >> P.S. We are having fun at GitTogether'08 in the first half of this week, >> so please expect slower response than usual. > Please see my next patch revision arriving here in a moment.