Understanding Git LFS's Insistence on At Least One Retry Despite Configuring Retries to 0 about git-lfs

[chrisd8088]

Hey, thanks for the question! From what I can tell, the lfs.transfer.maxRetries option was added in PR #1545 and the checks which require it to have a value of 1 or greater date from that time, but there's no particular explanation as to why that choice was made.

Our current documentation does state:

Must be an integer which is at least one.
which is at least a correct description of the current state of affairs.

If I had to guess, I imagine the current requirement for a minimum retry limit of 1 stems from a slight misapprehension when the code was first introduced that it would mean a maximum of a single request could be made, rather than one request, potentially followed by at most one retry (i.e., either one or at most two requests).

I'll mark this as a potential enhancement, to allow 0 as a setting for lfs.transfer.maxRetries.

[adlternative]

Hey, thanks for the question! From what I can tell, the lfs.transfer.maxRetries option was added in PR #1545 and the checks which require it to have a value of 1 or greater date from that time, but there's no particular explanation as to why that choice was made.

Our current documentation does state:

Must be an integer which is at least one.
which is at least a correct description of the current state of affairs.

If I had to guess, I imagine the current requirement for a minimum retry limit of 1 stems from a slight misapprehension when the code was first introduced that it would mean a maximum of a single request could be made, rather than one request, potentially followed by at most one retry (i.e., either one or at most two requests).

I'll mark this as a potential enhancement, to allow 0 as a setting for lfs.transfer.maxRetries.

Thanks, I believe this kind of enhancement is reasonable.