On Mon, 15 Jun 2009, Junio C Hamano wrote: > I guess both ssh and local would regress, and we do care about regressions > in general, but I think it is not a grave offense in this case, because > the combination between such an old fetch and the updated upload-pack will > still transfer the objects and will update the refs as expected; only the > progress indication and chatter on the stderr stream will be lost. My point exactly, although I realize I didn't make myself clear. > So I would say it is Ok to regress in this particular case, _if_ there is > no easy way to avoid it. That was why I asked: > > >> I think it is a very good idea to squelch progress output that will never > >> go to the client (it will be wasted traffic, regardless of the "syslog" > >> thing), but > >> > >> (1) Is "not using sideband" the same as "client won't see the progress > >> output" for all vintages of clients that work with the current > >> server? > > Stated differently, I think "not using sideband _and_ spawned via daemon" > would be an indication that "the client won't see the progress anyway even > if it were sent." So the question becomes "will it be a small enough > change to detect if the upload-pack is driven by the daemon in the > codepath J6t added 'if (!use_sideband)' to, and if so shouldn't we do so?" I don't think it is worth it at all. The regression is purely cosmetic, and I suspect you'll have a really hard time finding someone still using those ancient git clients anyway. Remember that such clients are unable to fetch with HTTP from repositories using version 2 of the pack index by default already. That's why we created version 1.4.4.5. Nicolas -- 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