On Tue, May 01, 2012 at 03:33:26AM -0400, Jeff King wrote: > In this case, send pack gets its arguments from the command-line, not > from the options set at the transport layer. Remote-curl will pass along > "--quiet" if we get that from the transport layer, but it does not > otherwise pass along the "progress" flag. So there are two problems: > > 1. send-pack defaults its progress boolean to 0. Before 01fdc21, that > was OK, because it meant "don't explicitly ask for progress". But > after 01fdc21 that now means "explicitly ask for no progress", and > the direct-transport code paths were updated without updating > cmd_send_pack. > > 2. There's no way to tell send-pack explicitly "yes, I would like > progress, no matter what isatty(2) says". I doubt anybody cares > much, but it probably makes sense to handle that for the sake of > completeness. The following patch series fixes this: [1/3]: send-pack: show progress when isatty(2) [2/3]: teach send-pack about --[no-]progress [3/3]: t5541: test more combinations of --progress The first patch fixes (1) above, restoring send-pack's original behavior (for remote-curl as well as anybody else who happens to call it). Note that in doing so, it breaks "push --no-progress" for http remotes that 01fdc21 tried to fix. But it didn't actually fix it; it only appeared to work because progress was _never_ on for http. Fortunately, the existing test in t5541 still passes because it's poorly written (it uses both "--quiet" and "--no-progress", unmindful of the fact that the latter does absolutely nothing). The second patch fixes it correctly by propagating the options through remote-curl (and as a bonus, it makes (2) above work). Other transport helpers that use send-pack would want to do the same thing (but I don't know of any that exist). The third patch just expands the test coverage. These are prepared directly on top of 01fdc21, so they can go on the maint track. -Peff -- 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