Giters

git-lfs / git-lfs

Git extension for versioning large files

Home Page:https://git-lfs.com

Geek Repo:Geek Repo

Github PK Tool:Github PK Tool

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

adlternative opened this issue · comments

commented

Describe the issue
I'm encountering a situation where Git LFS seems to enforce at least one retry even when attempting to disable retries altogether. I was under the impression that configuring retries to 0 would prevent retry attempts entirely. Can someone clarify the logic behind having a minimum of one retry even when explicitly set not to?

Output of git lfs env
The output of running git lfs env as a code block.

lfs.transfer.maxretries=1
lfs.activitytimeout=0

commented

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.

commented

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.