نشانی اینترنتی (URL) مورد استفاده برای فراخوانی API ریموت Git LFS. پیش‌فرض خالی است (از URL کلون مشتق می‌شود).

نشانی اینترنتی (URL) مورد استفاده برای فراخوانی API ریموت Git LFS هنگام ارسال (push). پیش‌فرض خالی است (از URLهای غیر push مربوط به LFS یا URL کلون مشتق می‌شود).

ریموت مورد استفاده برای یافتن API ریموت Git LFS. گزینه‌های lfs.url و branch.*.remote برای شاخه جاری، بر این تنظیم اولویت دارند و آن را بازنویسی می‌کنند. اگر این تنظیم مشخص نشده باشد و دقیقاً یک ریموت وجود داشته باشد، همان ریموت انتخاب می‌شود؛ در غیر این صورت، پیش‌فرض origin است.

ریموت مورد استفاده برای یافتن API ریموت Git LFS هنگام ارسال (push). گزینه‌های lfs.url و branch.*.pushremote برای شاخه جاری، بر این تنظیم اولویت دارند و آن را بازنویسی می‌کنند. اگر این تنظیم مقداردهی نشده باشد، remote.pushdefault استفاده می‌شود، و اگر آن هم مشخص نباشد، ترتیب انتخاب همان‌طور که در remote.lfsdefault در بالا شرح داده شد اعمال می‌گردد.

این گزینه بولی، قابلیت تشخیص خودکار ریموت را در Git LFS فعال می‌کند. LFS تلاش می‌کند ریموت مربوطه را از اطلاعات کامیت به دست آورد و در صورت موفقیت، تنظیمات تعریف‌شده توسط remote.lfsdefault و remote.<remote>.lfsurl را نادیده می‌گیرد.

این گزینه بولی به Git LFS امکان می‌دهد برای یافتن داده‌های LFS در تمام ریموت‌های ثبت‌شده جستجو کند. این یک سازوکار پشتیبان (fallback) است که تنها در صورتی اجرا می‌شود که داده‌های LFS از طریق روش‌های عادی شرح داده شده در remote.lfsdefault، remote.<remote>.lfsurl و در صورت فعال بودن، lfs.remote.autodetect یافت نشوند.

حداکثر زمانی (به ثانیه) را تعیین می‌کند که کلاینت HTTP برای برقراری اتصال منتظر می‌ماند. این زمان شامل مدت ارسال درخواست و انتظار برای پاسخ نمی‌شود. پیش‌فرض: ۳۰ ثانیه.

حداکثر زمانی (به ثانیه) را تعیین می‌کند که کلاینت HTTP برای دست‌تکانی (handshake) TLS منتظر می‌ماند. پیش‌فرض: ۳۰ ثانیه.

حداکثر زمانی (به ثانیه) را تعیین می‌کند که کلاینت HTTP برای خواندن یا نوشتن TCP بعدی منتظر می‌ماند. اگر کمتر از ۱ باشد، هیچ مهلت زمانی برای فعالیت اعمال نمی‌شود. پیش‌فرض: ۳۰ ثانیه.

حداکثر زمانی (به ثانیه) را برای کلاینت HTTP جهت نگه‌داشتن اتصال‌های زنده (keepalive) تعیین می‌کند. پیش‌فرض: ۳۰ دقیقه.

هنگام استفاده از پروتکل خالص مبتنی بر SSH، مشخص می‌کند که آیا در صورت امکان درخواست‌ها روی یک اتصال واحد مالتی‌پلکس (multiplex) شوند یا خیر. این گزینه نیاز به استفاده از OpenSSH یا یک کلاینت سازگار با SSH دارد. پیش‌فرض: روی ویندوز false و در غیر این صورت true.

تعداد دفعاتی که Git LFS تلاش می‌کند تا قبل از متوقف شدن، از طریق SSH احراز هویت را دریافت کند مشخص می‌نماید. پیش‌فرض: ۵.

در صورتی که به عنوان یک برنامه و آرگومان‌های آن مشخص شود، هنگام نیاز به احراز هویت در برابر LFS API فراخوانی می‌شود. محتویات خروجی استاندارد (stdout) به عنوان گذرواژه تفسیر می‌گردد.

کش کردن درون‌حافظه‌ای اعتبارنامه‌های SSH و گیت را برای یک دستور واحد 'git lfs' فعال می‌کند. پیش‌فرض: فعال (enabled).

اندازه کش درون‌حافظه‌ای نتایج حاصل از تطبیق مسیر فایل‌ها با فیلتر تعریف‌شده توسط گزینه‌های lfs.fetchInclude و lfs.fetchExclude، یا برای دستوراتی که آن‌ها را می‌پذیرند توسط گزینه‌های خط فرمان --include و --exclude یا معادل‌های -I و -X آن‌ها را تنظیم می‌کند. برای غیرفعال کردن کش مقدار را روی 0 یا none و برای اجازه دادن به رشد نامحدود کش مقدار را روی unlimited تنظیم کنید. پیش‌فرض: ۱۰,۰۰۰ مسیر فایل یکتا.

امکان بازنویسی دایرکتوری ذخیره‌سازی LFS را فراهم می‌کند. مسیرهای غیرمطلق، نسبت به داخل دایرکتوری مخزن گیت (معمولاً .git) نسبی در نظر گرفته می‌شوند.

نکته: در صورتی که مخازن مختلفی دارید که از یک دایرکتوری ذخیره‌سازی مشترک استفاده می‌کنند، نباید دستور git lfs prune را اجرا کنید.

پیش‌فرض: lfs در دایرکتوری مخزن گیت (معمولاً .git/lfs).

هنگامی که یک فایل ۴ گیبی‌بایت (GiB) یا بزرگ‌تر باشد، هشدار می‌دهد. به دلیل محدودیتی در گیت، چنین فایل‌هایی هنگام استفاده از ویندوز با نسخه‌ای از Git for Windows کمتر از 2.34.0 آسیب خواهند دید (مگر اینکه smudge غیرفعال شده باشد). پیش‌فرض: اگر نسخه کمتر از 2.34.0 باشد true، و در غیر این صورت false.

تعداد بارگذاری‌ها/بارگیری‌های هم‌زمان. پیش‌فرض ۸ است.

اگر روی true تنظیم شود، فقط انتقال‌های پایه‌ای بارگذاری/بارگیری HTTP استفاده خواهند شد و هرگونه انتقال پیشرفته‌تری که کلاینت/سرور پشتیبانی کنند نادیده گرفته می‌شود. این گزینه در درجه اول برای دور زدن باگ‌ها یا ناسازگاری‌ها است.

کلاینت git-lfs از بارگیری‌های پایه HTTP، بارگیری‌های قابل ازسرگیری HTTP (با استفاده از هدرهای Range) و بارگذاری‌های قابل ازسرگیری از طریق پروتکل tus.io پشتیبانی می‌کند. روش‌های انتقال سفارشی را می‌توان از طریق lfs.customtransfer اضافه کرد (بخش بعدی را ببینید). با این حال، تنظیم این مقدار روی true، کلاینت را به HTTP ساده محدود می‌کند.

اگر روی true تنظیم شود، بارگذاری‌های قابل ازسرگیری اشیاء LFS را از طریق API وبگاه tus.io فعال می‌کند. پس از نهایی شدن این ویژگی، این تنظیم حذف خواهد شد و بارگذاری‌های tus.io برای همه کلاینت‌ها در دسترس خواهد بود.

اجازه می‌دهد تا عامل انتقال سفارشی مشخص‌شده مستقیماً برای انتقال فایل‌ها بدون استعلام از سرور درباره نحوه انجام انتقال استفاده شود. عامل انتقال سفارشی باید در گروه تنظیمات lfs.customtransfer.<name> تعریف شده باشد، یا اینکه مبدل انتقال داخلی lfs-standalone-file باشد. سایر مقادیر نادیده گرفته خواهند شد.

برای جزئیات مبدل انتقال سفارشی داخلی lfs-standalone-file، که برای استفاده با URLهای محلی <file:///> در نظر گرفته شده است، به git-lfs-standalone-file(1) مراجعه کنید.

گزینه lfs.customtransfer.<name> یک گروه تنظیمات است که یک قلاب انتقال سفارشی را تعریف می‌کند و به شما امکان می‌دهد با استفاده از هر سازوکاری که می‌خواهید (به جای صرفاً HTTP)، از طریق یک فرایند واسط به بارگذاری/بارگیری بپردازید. گزینه path باید به فرایندی اشاره کند که مایل به فراخوانی آن هستید. پروتکل بین کلاینت git-lfs و فرایند انتقال سفارشی در نشانی زیر مستند شده است: https://github.com/git-lfs/git-lfs/blob/main/docs/custom-transfers.md

شناسه <name> باید یک شناسه یکتا باشد که سرور LFS آن را بشناسد و با نام هیچ‌یک از مبدل‌های انتقال داخلی از پیش تعریف‌شده در کلاینت مانند «basic» یا «ssh» تداخل نداشته باشد، زیرا آن‌ها همواره یک مبدل انتقال سفارشی با همان نام را بازنویسی می‌کنند. کلاینت هنگام فراخوانی LFS API فهرستی از انواع انتقال‌های پشتیبانی‌شده را ارسال می‌کند. اگر سرور نیز از این نوع انتقالِ نام‌گذاری‌شده پشتیبانی کند، آن را انتخاب کرده و اقدامات بازگردانده شده از API در ارتباط با همان نوع انتقال خواهد بود (برای مثال ممکن است URLهای سنتی نباشند). این فرایند انتقال سفارشی تنها در صورتی فراخوانی می‌شود که سرور آن را به عنوان انتقالی که پشتیبانی می‌کند بپذیرد.

اگر چندین تنظیم lfs.customtransfer.<name> تعریف شده باشد، همگی باید در یک زیربخش پیکربندی یکسان قرار داشته باشند، به این معنی که بخش زیربخش نام آن‌ها باید دقیقاً یکسان باشد. به عنوان مثال، اگر lfs.customTransfer.myAdapter.path تعریف شود، آنگاه lfs.customTransfer.myAdapter.args پذیرفته خواهد شد، در حالی که lfs.customtransfer.myadapter.args پذیرفته نخواهد شد.

اگر فرایند انتقال سفارشی به هرگونه آرگومانی نیاز داشته باشد، می‌توان آن‌ها را در اینجا مشخص کرد. این رشته توسط شل (shell) بسط داده می‌شود.

اگر true باشد (پیش‌فرض)، git-lfs فرایند انتقال سفارشی را چند بار به صورت موازی بر اساس lfs.concurrenttransfers فراخوانی می‌کند و بار کاری انتقال را بین فرایندها تقسیم می‌نماید.

مشخص می‌کند که فرایند انتقال سفارشی از کدام جهت پشتیبانی می‌کند: «download»، «upload» یا «both». در صورت عدم تعیین، پیش‌فرض «both» است.

کدگذاری فشرده‌سازی مورد استفاده هنگام بارگیری اشیاء LFS از طریق HTTP را مشخص می‌کند. مقادیر معتبر عبارتند از gzip یا zstdgzip است.

این گزینه ممکن است به صورت انتخابی روی برخی URLها اعمال شود و از همان قوانین تطبیق تعریف‌شده برای گزینه‌های http.<url>.* در گیت پیروی کند: گزینه‌ها https://git-scm.com/docs/git-config#Documentation/git-config.txt-httplturlgt. به عنوان مثال، برای تنظیم این گزینه تنها برای یک میزبان خاص، استفاده کنید از:

git config lfs.transfer.https://example.com/.httpDownloadEncoding zstd

مشخص می‌کند که LFS قبل از علامت‌گذاری انتقال به عنوان ناموفق، چند بار تلاش مجدد به ازای هر OID انجام دهد. باید یک عدد صحیح و حداقل برابر با یک باشد. اگر مقدار عدد صحیح نباشد، کمتر از یک باشد یا مشخص نشود، مقدار هشت استفاده خواهد شد.

حداکثر زمان (به ثانیه) را تعیین می‌کند که LFS بین هر تلاش مجدد منتظر خواهد ماند. LFS از عقب‌نشینی نمایی (exponential backoff) برای تلاش‌های مجدد استفاده می‌کند و زمان بین هر تلاش را دو برابر می‌کند تا به این حد برسد. اگر سروری با استفاده از هدر Retry-After درخواست تاخیر کند، مقدار هدر تاخیر نمایی را برای آن تلاش بازنویسی می‌کند و محدود به این گزینه نخواهد بود.

باید یک عدد صحیح غیرمنفی باشد. از صفر برای غیرفعال کردن تاخیر بین تلاش‌های مجدد استفاده کنید، مگر اینکه توسط سرور درخواست شده باشد. اگر مقدار عدد صحیح نباشد، منفی باشد، یا مشخص نشود، مقدار ده استفاده خواهد شد.

حداکثر زمان (به ثانیه) را تعیین می‌کند که LFS قبل از لغو یک انتقال منتظر خواهد ماند، در زمانی که سرور با استفاده از هدر Retry-After درخواست تاخیر کند. اگر سرور زمان انتظاری طولانی‌تر از این مقدار را مشخص کند، LFS به جای صبر کردن برای کل مدت درخواست‌شده، یک هشدار ثبت کرده و انتقال را به عنوان ناموفق علامت‌گذاری می‌کند.

باید یک عدد صحیح و حداقل برابر با یک باشد. اگر مقدار عدد صحیح نباشد، کمتر از یک باشد یا مشخص نشود، مقدار ۳۰۰ به جای آن استفاده خواهد شد.

مشخص می‌کند در صورتی که شیء دارای یک اقدام راستی‌آزمایی مرتبط باشد، LFS چند درخواست راستی‌آزمایی به ازای هر OID قبل از علامت‌گذاری انتقال به عنوان ناموفق انجام خواهد داد. باید یک عدد صحیح و حداقل برابر با یک باشد. اگر مقدار عدد صحیح نباشد، کمتر از یک باشد یا مشخص نشود، مقدار پیش‌فرض سه استفاده خواهد شد.

اگر روی true تنظیم شود، بازنویسی href اشیاء LFS را با استفاده از پیکربندی url.*.insteadof/pushinsteadof فعال می‌کند. گزینه pushinsteadof فقط برای بارگذاری استفاده می‌شود، و insteadof برای بارگیری و همچنین برای بارگذاری در زمانی که pushinsteadof تنظیم نشده باشد استفاده می‌گردد.

تعداد اشیاء برای بارگیری/بارگذاری که در یک درخواست دسته‌ای (batch) واحد به سرور LFS ارسال می‌شوند. پیش‌فرض ۱۰۰ است.

این مقدار باید با احتیاط تغییر داده شود، چرا که می‌تواند تاثیر چشمگیری بر کارایی سرور LFS بگذارد؛ همچنین همان‌طور که در مشخصات Batch API ذکر شده است، سرور در صورت بیش از حد بالا بودن این مقدار مجاز است کد وضعیت HTTP 413 را برگرداند.

هنگام ارسال (push)، اجازه می‌دهد اشیاء بدون متوقف کردن فرایند ارسال گیت، در کش محلی وجود نداشته باشند. پیش‌فرض: false.

هنگام واکشی (fetch)، فقط اشیائی را بارگیری می‌کند که با هر یک از موارد این فهرست جداشده با کاما از مسیرها/نام‌فایل‌ها مطابقت داشته باشند. تطبیق نویسه‌های عمومی (wildcard) مطابق با gitignore(5) است. برای مشاهده مثال‌ها به git-lfs-fetch(1) مراجعه کنید.

هنگام واکشی (fetch)، اشیائی را که با هر یک از موارد این فهرست جداشده با کاما از مسیرها/نام‌فایل‌ها مطابقت دارند بارگیری نمی‌کند. تطبیق نویسه‌های عمومی (wildcard) مطابق با gitignore(5) است. برای مشاهده مثال‌ها به git-lfs-fetch(1) مراجعه کنید.

اگر غیرصفر باشد، ارجاعاتی (refs) را که دارای کامیت‌هایی در بازه N روز از تاریخ جاری هستند واکشی می‌کند. فقط ارجاعات محلی گنجانده می‌شوند مگر اینکه lfs.fetchrecentremoterefs برابر با true باشد. همچنین به عنوان مبنایی برای پاک‌سازی (prune) فایل‌های قدیمی استفاده می‌شود. پیش‌فرض ۷ روز است.

اگر true باشد، ارجاعات ریموت (برای ریموتی که در حال واکشی آن هستید) و همچنین ارجاعات محلی در بازه زمانی اخیر را واکشی می‌کند. این گزینه برای دریافت اشیاء مربوط به شاخه‌های ریموتی که ممکن است بعداً بخواهید دریافت (checkout) کنید، مفید است. پیش‌فرض true است؛ اگر آن را روی false تنظیم کنید، واکشی برای آن شاخه‌ها تنها زمانی رخ می‌دهد که آن‌ها را دریافت کنید (که مزیت fetch --recent از دست می‌رود)، یا اینکه یک شاخه محلی ردیاب را جداگانه ایجاد کرده و سپس دوباره واکشی کنید.

علاوه بر واکشی در ارجاعات، تغییرات قبلی انجام‌شده در بازه N روز از آخرین کامیت روی ارجاع را نیز واکشی می‌کند. این گزینه زمانی که مرتباً تغییرات اخیر را بازبینی می‌کنید مفید است. همچنین به عنوان مبنایی برای پاک‌سازی فایل‌های قدیمی استفاده می‌شود. پیش‌فرض ۰ است (بدون تغییرات قبلی).

همیشه طوری عمل می‌کند که گویی گزینه --recent در فراخوانی git lfs fetch گنجانده شده است. پیش‌فرض false است.

تعداد روزهایی که به تنظیمات lfs.fetchrecent* اضافه می‌شود تا مشخص گردد چه مواردی را می‌توان پاک‌سازی کرد. پیش‌فرض ۳ روز است، به این معنی که هر چیزی که در قدیمی‌ترین لبه «بازه اخیر» واکشی شده باشد، ۳ روز بعد واجد شرایط پاک‌سازی خواهد بود.

ریموت مورد نظری را تعیین می‌کند که فایل‌های LFS باید به آن ارسال (push) شده باشند تا برای پاک‌سازی محلی واجد شرایط شناخته شوند. همچنین این همان ریموتی است که در صورت فعال بودن --verify-remote فراخوانی می‌شود.

همیشه دستور git lfs prune را به گونه‌ای اجرا می‌کند که گویی --verify-remote مشخص شده است.

همیشه دستور git lfs prune را به گونه‌ای اجرا می‌کند که گویی --verify-unreachable مشخص شده است.

افزونه‌های Git LFS دستکاری جریان‌های فایل را در طول فرایندهای smudge و clean امکان‌پذیر می‌سازند. name تنظیمات مربوط به یک افزونه واحد را گروه‌بندی می‌کند و تنظیمات عبارتند از:

clean: دستوری که هنگام اضافه شدن فایل‌ها به ایندکس اجرا می‌شود
smudge: دستوری که هنگام نوشته شدن فایل‌ها در نسخه کاری (working copy) اجرا می‌شود
priority: اولویت و ترتیب این افزونه در مقایسه با سایر افزونه‌ها

نکته: این تنظیم معمولاً توسط خود LFS پس از دریافت پاسخ 401 (نیاز به احراز هویت) مقداردهی می‌شود؛ شما معمولاً نیازی به تنظیم دستی آن ندارید.

اگر روی «basic» تنظیم شود، قبل از ایجاد درخواست‌های دسته‌ای (batch) به این URL، اعتبارنامه‌ها درخواست خواهند شد؛ در غیر این صورت، در ابتدا یک درخواست عمومی انجام خواهد شد.

تعیین می‌کند که آیا قفل‌ها قبل از ارسال‌های گیت بررسی شوند یا خیر. این کار مانع از آن می‌شود که تغییرات فایل‌هایی را که سایر کاربران قفل کرده‌اند ارسال کنید. قلاب پیش از ارسال (pre-push hook) در Git LFS رفتار خود را بر اساس مقدار این کلید پیکربندی تغییر می‌دهد.

null - در صورت عدم وجود مقدار، Git LFS تلاش می‌کند فراخوانی را انجام دهد، و در صورتی که خطایی برگرداند هشدار می‌دهد. اگر پاسخ معتبر باشد، Git LFS مقدار را روی true تنظیم می‌کند و اگر کاربر تلاش کند فایلی را که توسط کاربر دیگری قفل شده به‌روزرسانی کند، ارسال را متوقف خواهد کرد. اگر سرور پاسخ 501 Not Implemented را برگرداند، Git LFS مقدار را روی false تنظیم خواهد کرد.

true - دستور Git LFS تلاش می‌کند قفل‌ها را راستی‌آزمایی کند، و در صورت بروز هرگونه مشکل سرور یا تلاش کاربر برای به‌روزرسانی فایلی که توسط کاربر دیگری قفل شده، ارسال گیت را متوقف می‌سازد.

false - دستور Git LFS بررسی قفل را در قلاب پیش از ارسال کاملاً نادیده می‌گیرد. در صورتی که از قفل‌گذاری فایل (File Locking) استفاده نمی‌کنید، یا سرور گیت شما فایل‌های قفل‌شده را در زمان ارسال به صورت خودکار راستی‌آزمایی می‌کند، باید این مقدار را تنظیم کنید.

از جستجوی پیکربندی URL همان‌طور که شرح داده شده پشتیبانی می‌کند: https://git-scm.com/docs/git-config#Documentation/git-config.txt-httplturlgt. برای تنظیم این مقدار به ازای هر میزبان:

git config --global lfs.https://github.com/.locksverify [true|false].

مشخص می‌کند که آیا انتقال‌های SSH (پروتکل خالص SSH) استفاده شوند یا خیر. به طور پیش‌فرض (یا اگر مقدار روی negotiate تنظیم شده باشد)، ابتدا پروتکل خالص SSH امتحان می‌شود و سپس پروتکل ترکیبی قدیمی‌تر. اگر always استفاده شود، فقط پروتکل خالص SSH امتحان خواهد شد. به همین ترتیب، اگر never استفاده شود، فقط پروتکل ترکیبی امتحان می‌شود.

تعیین می‌کند که آیا Git LFS هنگام بارگذاری با استفاده از مبدل بارگذاری 'basic' باید تلاش کند یک هدر مناسب Content-Type در HTTP را تشخیص دهد یا خیر. در صورت تنظیم روی false، هدر پیش‌فرض Content-Type: application/octet-stream به جای آن انتخاب می‌شود. پیش‌فرض: 'true'.

باعث می‌شود Git LFS هنگام مواجهه با خطای بارگیری، فیلتر smudge را متوقف نکند؛ این امر امکان انجام اقداماتی مانند checkout را حتی در زمانی که قادر به بارگیری محتوای LFS نیستید، فراهم می‌کند. فایل‌های LFS که امکان بارگیری آن‌ها وجود نداشته، حاوی محتوای اشاره‌گر (pointer) خواهند بود.

توجه داشته باشید که این امر باعث می‌شود دستورات گیت که فیلتر smudge را فراخوانی می‌کنند، حتی در مواردی که بارگیری‌های LFS با شکست مواجه می‌شوند موفقیت را گزارش کنند، که ممکن است بر اسکریپت‌ها اثر بگذارد.

همچنین می‌توانید متغیر محیطی GIT_LFS_SKIP_DOWNLOAD_ERRORS=1 را برای رسیدن به همین نتیجه تنظیم کنید.

این متغیر محیطی باعث می‌شود Git LFS هنگام انجام عملیات cleaning، smudging یا fetching، وضعیت پیشرفت را در یک مسیر فایل مطلق روی دیسک بنویسد.

پیشرفت به طور دوره‌ای به صورت افزودن یک سطر جدید به انتهای فایل گزارش می‌شود. هر سطر جدید در قالب زیر خواهد بود:

<direction> <current>/<total files> <downloaded>/<total> <name>

هر فیلد در زیر توضیح داده شده است:

direction: جهت انتقال، شامل «checkout»، «download» یا «upload».
current: شاخص فایلی که در حال حاضر منتقل می‌شود.
total files: تعداد تخمینی تمامی فایل‌هایی که باید منتقل شوند.
downloaded: تعداد بایت‌هایی که تاکنون بارگیری شده است.
total: کل اندازه فایل به بایت.
name: نام فایل.

کنترل می‌کند که آیا Git LFS زمانی که جریان خروجی استاندارد به یک ترمینال متصل نیست، نمایش وضعیت پیشرفت را متوقف کند یا خیر. پیش‌فرض false است که باعث می‌شود Git LFS تشخیص دهد که آیا stdout یک ترمینال است یا خیر و در صورتی که ترمینال نباشد پیشرفت را متوقف سازد؛ شما می‌توانید این رفتار را غیرفعال کرده و حتی زمانی که جریان خروجی استاندارد ترمینال نیست، با تنظیم هر یک از این متغیرها روی 1، 'yes' یا 'true'، نمایش وضعیت پیشرفت را اجباری کنید.

مشخص می‌کند که آیا Git LFS هنگام دریافت (checkout) فایل‌ها در نسخه کاری، از تلاش برای تبدیل اشاره‌گرهای فایل‌های ردیابی‌شده به اشیاء متناظر آن‌ها صرف‌نظر کند یا خیر. اگر روی 'true'، '1'، 'on' یا موارد مشابه تنظیم شود، Git LFS از فرایند smudge در هر دو دستور git lfs smudge و git lfs filter-process صرف‌نظر خواهد کرد. در صورت عدم مقداردهی، یا تنظیم روی 'false'، '0'، 'off' یا موارد مشابه، Git LFS فایل‌ها را به صورت عادی smudge خواهد کرد.

مشخص می‌کند که آیا Git LFS در یک قلاب پیش از ارسال (pre-push hook) برای بارگذاری شیء جدید Git LFS تلاش کند یا خیر. اگر روی 'true'، '1'، 'on' یا موارد مشابه تنظیم شود، Git LFS قلاب پیش از ارسال را نادیده می‌گیرد، بنابراین هیچ شیء جدید Git LFS بارگذاری نخواهد شد. در صورت عدم مقداردهی، یا تنظیم روی 'false'، '0'، 'off' یا موارد مشابه، Git LFS طبق روال عادی عمل خواهد کرد.

این تنظیمات که اولی یک متغیر محیطی و دومی یک تنظیم gitconfig است، کنترل می‌کنند که آیا فایل‌هایی که در git lfs track به عنوان 'lockable' علامت‌گذاری شده‌اند، زمانی که توسط کاربر جاری قفل نشده‌اند در نسخه کاری به صورت فقط‌خواندنی (read-only) درآیند یا خیر. پیش‌فرض true است؛ شما می‌توانید این رفتار را غیرفعال کرده و با تنظیم هر یک از متغیرها روی 0، 'no' یا 'false'، همه فایل‌ها را قابل نوشتن کنید.

این تنظیم کنترل می‌کند که آیا Git LFS علاوه بر فایل‌های ردیابی‌شده، فایل‌های نادیده‌گرفته‌شده‌ای (ignored) را که با الگوی قفل‌شدنی مطابقت دارند نیز فقط‌خواندنی کند یا خیر. پیش‌فرض false است؛ می‌توانید این رفتار را با تنظیم این متغیر روی 1، 'yes' یا 'true' فعال کنید.

این تنظیم، مقدار پیش‌فرض زمان حیات (TTL) توکن را هنگامی که git-lfs-authenticate مقدار TTL را در پاسخ JSON نگنجانده اما همچنان آن را اعمال می‌کند، تعیین می‌نماید.

توجه داشته باشید که این کار فقط برای مخازن بزرگ‌تری که روی سرورهای LFS میزبانی می‌شوند و TTL را درج نمی‌کنند ضروری است.