On Sat, Mar 08, 2008 at 08:04:26PM -0800, Junio C Hamano wrote: > Iustin Pop <iusty@xxxxxxxxx> writes: > > > Although git pull has a documented quiet option,... > > I think that is a documentation bug. pull accepts all options for fetch > for the sole purpose of passing them intact to underlying fetch, and some > options to fetch does not even make much sense in the context of pull. > > Also options to pull needs to come first; the options pull does not know > about is a signal for pull that the rest is for consumption of underlying > fetch. Ah, I see. This is indeed not clear from the documentation. > If you want to teach --quiet to pull, however, your patch is the right > approach. pull would eat --quiet and make a note for itself, and passes > that to underlying fetch (and perhaps merge). > > You also need to sign-off your patch and add tests to make sure that other > people will not break your enhancement in the future. Thanks, so the approach would be: - resend git merge patch including tests - and then resend git pull patch, again including tests. Thanks for the feedback, I will try to see how the unittests are written and hopefully come back with some more patches. iustin -- 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