Lars Schneider [off-list ref] writes:
quoted
If we do the success first and then error out halfway, we
still have to clean up, so I do not see how this impacts
implementation?
That is true. The reasoning is that an error in between is somewhat
less expected. Therefore additional work is OK.
An error upfront is much more likely because it is also a mechanism
for the filter to reject certain files. If the filter is configured
as "required=false" then this reject would actually be OK.
Unless the reasoning is "an error in between is so rare that we are
OK if the protocol misbehaves and the receiving end omits error
handing", I am not so sure how "therefore additional work is OK" is
a reasonable conclusion.
On 12 Aug 2016, at 19:13, Junio C Hamano [off-list ref] wrote:
Lars Schneider [off-list ref] writes:
quoted
quoted
If we do the success first and then error out halfway, we
still have to clean up, so I do not see how this impacts
implementation?
That is true. The reasoning is that an error in between is somewhat
less expected. Therefore additional work is OK.
An error upfront is much more likely because it is also a mechanism
for the filter to reject certain files. If the filter is configured
as "required=false" then this reject would actually be OK.
Unless the reasoning is "an error in between is so rare that we are
OK if the protocol misbehaves and the receiving end omits error
handing", I am not so sure how "therefore additional work is OK" is
a reasonable conclusion.
Maybe I need to reword. An error is detected in either way if something
goes wrong. The advantage of the two step status is that if we fail early
then Git does not even need to create structures to read the response.
See Peff's answer here:
http://public-inbox.org/git/20160806121421.bs7n4lhed7phdshb%40sigill.intra.peff.net/
http://public-inbox.org/git/20160805222710.chefh5kiktyzketh%40sigill.intra.peff.net/
Thanks,
Lars