On Sat, Nov 1, 2008 at 6:23 PM, Tuncer Ayaz <tuncer.ayaz@xxxxxxxxx> wrote: > On Tue, Oct 28, 2008 at 4:21 AM, Junio C Hamano <gitster@xxxxxxxxx> wrote: >> Nanako Shiraishi <nanako3@xxxxxxxxxxx> writes: >> >>> Quoting Tuncer Ayaz <tuncer.ayaz@xxxxxxxxx>: >>> >>>> 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. -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
