Nicolas Pitre <nico@xxxxxxx> writes: >> How did we drive upload-pack over native or ssh connection before we >> introduced sideband? I vaguely recall that we relied on stderr going >> to the invoking terminal in the local case. With this change, does >> the user suddenly stop seeing progress if the client is older than >> 583b7ea (upload-pack/fetch-pack: support side-band communication, >> 2006-06-21)? If so, that would be a regression. > > Native, or git:// style, certainly never was able to get any kind of > progress display without sideband support. > > As to old clients using ssh... well... that could be a regression. But > do we really care? This is pre v1.4.1 after all, and even the previous > Debian stable was using a later git version. 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. 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?" -- 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