On Wed, Dec 3, 2008 at 8:54 AM, Junio C Hamano <gitster@xxxxxxxxx> wrote: > Tuncer Ayaz <tuncer.ayaz@xxxxxxxxx> writes: > >> This is needed on top of the fetch/pull -q/-v changes >> to make >> $ git pull --rebase -q >> as quiet as expected. > > I am not sure if this is worth it, in the sense that it is not really > quiet enough (iow, it is not what I expect even though you claim "as Junio, sorry for using 'expected'. I thought about the wording while writing and had a feeling that 'expected' may be too strong as it's my opinion only. I should have listened to myself :). > expected" here), and in another sense that making it really quiet may not > be what we want anyway. I mainly use -q in automation where I only want output if something goes wrong. Just like good old cp or mv do. Do you think this is the wrong way to go? > How are you dealing with messages from the actual replaying of each local > commit on top of what is fetched? In order to be able to tell where you > are when one of them fail in conflicts, you cannot stay silent while doing > so. Fair point. Log messages that are of importance to a failure should ideally be sent to stderr but I think caching log messages for the failure case would over-complicate much of the code and is not worth it. Also you may not always know which part of stdout messages are useful for the failure case and not getting the same messages on a rerun for many commands makes this hard to trace back, yeah. As we've quietened pull/fetch/clone in a major already I am OK with leaving this change out. I'm definitely not advocating adding/changing anything when it's not clear we want the changed behavior. It's easier to keep out than to remove it later on :). -- 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
