Clemens Buchacher [off-list ref] writes:
Commit 90a6c7d4 (propagate --quiet to send-pack/receive-pack)
introduced the --quiet option to receive-pack and made send-pack
pass that option. Older versions of receive-pack do not recognize
the option, however, and terminate immediately.
This change restores backwards compatibility by adding a 'quiet'
capability to receive-pack.
Wouldn't this mean that there is no point in adding --quiet command line
option to the receive-pack command? IOW, shouldn't parts of 90a6c7d
(propagate --quiet to send-pack/receive-pack, 2011-07-30) be reverted?
At this late stage in the release cycle, I would rather prefer to revert
the whole commit and leave anything new for the next cycle.
On Tue, Sep 06, 2011 at 11:01:44AM -0700, Junio C Hamano wrote:
Clemens Buchacher [off-list ref] writes:
quoted
Commit 90a6c7d4 (propagate --quiet to send-pack/receive-pack)
introduced the --quiet option to receive-pack and made send-pack
pass that option. Older versions of receive-pack do not recognize
the option, however, and terminate immediately.
This change restores backwards compatibility by adding a 'quiet'
capability to receive-pack.
Wouldn't this mean that there is no point in adding --quiet command line
option to the receive-pack command? IOW, shouldn't parts of 90a6c7d
(propagate --quiet to send-pack/receive-pack, 2011-07-30) be reverted?
At this late stage in the release cycle, I would rather prefer to revert
the whole commit and leave anything new for the next cycle.
Sure, we can do that. Only then 1.7.6.1 will be broken against all
versions except 1.7.6.1 on the server side. Right now it is only
broken against 1.7.6 and older versions.
But I am ok with it either way. I will have to check how much
resolving needs to be done after the revert.
Clemens