git-annex(1) General Commands Manual git-annex(1)

git-annex - مدیریت فایل‌ها با گیت بدون ذخیره محتوای آن‌ها در مخزن

git annex command [params ...]

ابزار git-annex امکان مدیریت فایل‌ها با گیت را بدون ثبت محتوای فایل درون گیت فراهم می‌کند. اگرچه ممکن است این موضوع متناقض به نظر برسد، اما هنگام مواجهه با فایل‌هایی که از توانایی گیت برای مدیریت آسان فراتر هستند، خواه به دلیل محدودیت‌های حافظه، زمان محاسبه جمع کنترلی (checksum) یا فضای دیسک، بسیار مفید است.

حتی بدون ردیابی محتوای فایل‌ها، امکان مدیریت فایل‌ها با گیت، جابه‌جایی و حذف آن‌ها همراه با درخت‌های دایرکتوری نسخه‌بندی‌شده و بهره‌گیری از شاخه‌ها و شبیه‌سازی‌های توزیع‌شده (clones)، همگی دلایل بسیار کاربردی برای استفاده از گیت هستند. همچنین فایل‌های ضمیمه‌شده (annexed) می‌توانند در کنار فایل‌های معمولی دارای نسخه‌بندی در یک مخزن گیت همزیستی داشته باشند؛ این ویژگی برای نگهداری اسناد، Makefileها و سایر مواردی که با فایل‌های ضمیمه‌شده مرتبط هستند اما از کنترل کامل نسخه بهره‌مند می‌شوند، بسیار مناسب است.

هنگامی که فایلی ضمیمه (annex) می‌شود، محتوای آن به یک مخزن کلید-مقدار (key-value store) منتقل شده و یک پیوند نمادین (symlink) ساخته می‌شود که به آن محتوا اشاره می‌کند. این پیوندهای نمادین مانند فایل‌های معمولی در گیت ثبت و نسخه‌بندی می‌شوند. شما می‌توانید آن‌ها را جابه‌جا یا حذف کنید و غیره. ارسال (push) به یک مخزن گیت دیگر، git-annex موجود در آنجا را از فایل ضمیمه‌شده مطلع می‌کند و می‌تواند برای دریافت محتوای آن از مخزن کلید-مقدار به کار رود.

# git annex get video/hackity_hack_and_kaxxt.mov
get video/hackity_hack_and_kaxxt.mov (not available)
  I was unable to access these remotes: server
  Try making some of these repositories available:
  	5863d8c0-d9a9-11df-adb2-af51e6559a49  -- my home file server
   	58d84e8a-d9ae-11df-a1aa-ab9aa8c00826  -- portable USB drive
   	ca20064c-dbb5-11df-b2fe-002170d25c55  -- backup SATA drive
failed
# sudo mount /media/usb
# git remote add usbdrive /media/usb
# git annex get video/hackity_hack_and_kaxxt.mov
get video/hackity_hack_and_kaxxt.mov (from usbdrive...) ok
# git annex add iso
add iso/Debian_5.0.iso ok
# git annex drop iso/Debian_4.0.iso
drop iso/Debian_4.0.iso ok
# git annex move iso --to=usbdrive
move iso/Debian_5.0.iso (moving to usbdrive...) ok

نمایش راهنمای داخلی.
برای راهنمایی درباره یک دستور خاص، از git annex help command استفاده کنید.
فایل‌ها را به ضمیمه اضافه می‌کند.
برای جزئیات بیشتر به git-annex-add(1) مراجعه کنید.
محتوای فایل‌های ضمیمه‌شده را در این مخزن در دسترس قرار می‌دهد.
برای جزئیات بیشتر به git-annex-get(1) مراجعه کنید.
محتوای فایل‌های ضمیمه‌شده را از این مخزن حذف می‌کند.
برای جزئیات بیشتر به git-annex-drop(1) مراجعه کنید.
محتوای فایل‌ها را از یا به یک مخزن دوردست (remote) دیگر منتقل می‌کند.
برای جزئیات بیشتر به git-annex-move(1) مراجعه کنید.
محتوای فایل‌ها را از یا به یک مخزن دوردست دیگر کپی می‌کند.
برای جزئیات بیشتر به git-annex-copy(1) مراجعه کنید.
وضعیت درخت کاری را نمایش می‌دهد. (منسوخ‌شده)
برای جزئیات بیشتر به git-annex-status(1) مراجعه کنید.
قفل فایل‌های ضمیمه‌شده را برای اعمال تغییرات باز می‌کند.
برای جزئیات بیشتر به git-annex-unlock(1) مراجعه کنید.
این یک نام مستعار برای دستور unlock است. اگر به عنوان امکانی برای ویرایش یک فایل ضمیمه‌شده به آن فکر کنید، ممکن است به خاطر سپردن آن آسان‌تر باشد.
اگر نمی‌خواهید فایل‌ها را تغییر دهید یا تغییراتی ایجاد کرده‌اید که می‌خواهید لغو شوند، از این برای لغو دستور unlock استفاده کنید.
برای جزئیات بیشتر به git-annex-lock(1) مراجعه کنید.
محتوا را از مخازن دوردست دریافت (pull) می‌کند.
برای جزئیات بیشتر به git-annex-pull(1) مراجعه کنید.
محتوا را به مخازن دوردست ارسال (push) می‌کند.
برای جزئیات بیشتر به git-annex-push(1) مراجعه کنید.
مخزن محلی را با مخازن دوردست همگام‌سازی می‌کند.
برای جزئیات بیشتر به git-annex-sync(1) مراجعه کنید.
فایل‌ها را اضافه کرده و تغییرات را با مخازن دوردست همگام می‌کند.
برای جزئیات بیشتر به git-annex-assist(1) مراجعه کنید.
تنظیمات محتوای ترجیحی را با انتقال و حذف محتوا برآورده می‌سازد.
برای جزئیات بیشتر به git-annex-satisfy(1) مراجعه کنید.
محتوای فایل‌ها را به/از یک مخزن دیگر آینه‌سازی (mirror) می‌کند.
برای جزئیات بیشتر به git-annex-mirror(1) مراجعه کنید.
هر نشانی اینترنتی (url) را در فایل خودش بارگیری کرده و آن را به ضمیمه اضافه می‌کند.
برای جزئیات بیشتر به git-annex-addurl(1) مراجعه کنید.
ثبت می‌کند که فایل دیگر در آن نشانی اینترنتی در دسترس نیست.
برای جزئیات بیشتر به git-annex-rmurl(1) مراجعه کنید.
یک درخت از فایل‌ها را به مخزن اضافه می‌کند.
برای جزئیات بیشتر به git-annex-import(1) مراجعه کنید.
محتویات فیدهای پادکست را به ضمیمه وارد می‌کند.
برای جزئیات بیشتر به git-annex-importfeed(1) مراجعه کنید.
محتوا را به یک مخزن دوردست صادر می‌کند.
برای جزئیات بیشتر به git-annex-export(1) مراجعه کنید.
آخرین تغییر در یک فایل یا دایرکتوری را لغو می‌کند.
برای جزئیات بیشتر به git-annex-undo(1) مراجعه کنید.
فایل‌های محاسبه‌شده را به مخزن اضافه می‌کند.
برای جزئیات بیشتر به git-annex-addcomputed(1) مراجعه کنید.
فایل‌های محاسبه‌شده را مجدداً محاسبه می‌کند.
برای جزئیات بیشتر به git-annex-recompute(1) مراجعه کنید.
فایل‌های محاسبه‌شده را فهرست می‌کند.
برای جزئیات بیشتر به git-annex-findcomputed(1) مراجعه کنید.
توزیع چندپخشی (multicast) فایل‌ها.
برای جزئیات بیشتر به git-annex-multicast(1) مراجعه کنید.
دیمن برای نظارت بر تغییرات و ثبت خودکار تغییرات در کامیت (autocommit).
برای جزئیات بیشتر به git-annex-watch(1) مراجعه کنید.
دیمن برای همگام‌سازی خودکار تغییرات.
برای جزئیات بیشتر به git-annex-assistant(1) مراجعه کنید.
یک برنامه تحت وب را باز می‌کند که امکان راه‌اندازی آسان مخزن git-annex و کنترل دستیار git-annex را فراهم می‌آورد. اگر دستیار از قبل در حال اجرا نباشد، راه‌اندازی خواهد شد.
برای جزئیات بیشتر به git-annex-webapp(1) مراجعه کنید.
امکان دسترسی به مخزن git-annex از طریق HTTP را با استفاده از پروتکل p2p ابزار git-annex فراهم می‌کند.
برای جزئیات بیشتر به git-annex-p2phttp(1) مراجعه کنید.
ارتباط مداوم و پایدار با مخازن دوردست.
برای جزئیات بیشتر به git-annex-remotedaemon(1) مراجعه کنید.

تا زمانی که یک مخزن (یا یکی از مخازن دوردست آن) مقداردهی اولیه نشده باشد، git-annex برای جلوگیری از استفاده تصادفی در مخزنی که قرار نبوده است ضمیمه داشته باشد، از کار بر روی آن امتناع می‌ورزد.
برای جزئیات بیشتر به git-annex-init(1) مراجعه کنید.
توضیحات یک مخزن را تغییر می‌دهد.
برای جزئیات بیشتر به git-annex-describe(1) مراجعه کنید.
یک مخزن دوردست ویژه (special remote) جدید ایجاد کرده و آن را به .git/config می‌افزاید.
برای جزئیات بیشتر به git-annex-initremote(1) مراجعه کنید.
استفاده از یک مخزن دوردست ویژه موجود را در مخزن فعلی فعال می‌کند.
برای جزئیات بیشتر به git-annex-enableremote(1) مراجعه کنید.
پیکربندی یک مخزن دوردست ویژه موجود را تغییر می‌دهد.
برای جزئیات بیشتر به git-annex-configremote(1) مراجعه کنید.
نام یک مخزن دوردست ویژه را تغییر می‌دهد.
برای جزئیات بیشتر به git-annex-renameremote(1) مراجعه کنید.
سرویس مخفی تور (tor hidden service) را راه‌اندازی می‌کند.
برای جزئیات بیشتر به git-annex-enable-tor(1) مراجعه کنید.
تعداد نسخه‌های مطلوب را پیکربندی می‌کند.
برای جزئیات بیشتر به git-annex-numcopies(1) مراجعه کنید.
حداقل تعداد نسخه‌ها را پیکربندی می‌کند.
برای جزئیات بیشتر به git-annex-mincopies(1) مراجعه کنید.
ثبت می‌کند که یک مخزن مورد اعتماد است تا به طور غیرمنتظره محتوا را از دست ندهد. با احتیاط استفاده شود.
برای جزئیات بیشتر به git-annex-trust(1) مراجعه کنید.
ثبت می‌کند که یک مخزن غیرقابل‌اعتماد است و ممکن است هر زمانی محتوا را از دست بدهد.
برای جزئیات بیشتر به git-annex-untrust(1) مراجعه کنید.
یک مخزن را به وضعیت پیش‌فرض نیمه‌قابل‌اعتماد بازمی‌گرداند.
برای جزئیات بیشتر به git-annex-semitrust(1) مراجعه کنید.
یک مخزن را به یک گروه اضافه می‌کند.
برای جزئیات بیشتر به git-annex-group(1) مراجعه کنید.
یک مخزن را از یک گروه حذف می‌کند.
برای جزئیات بیشتر به git-annex-ungroup(1) مراجعه کنید.
عبارت محتوای ترجیحی را دریافت یا تنظیم می‌کند.
برای جزئیات بیشتر به git-annex-wanted(1) مراجعه کنید.
عبارت محتوای ترجیحی گروه را دریافت یا تنظیم می‌کند.
برای جزئیات بیشتر به git-annex-groupwanted(1) مراجعه کنید.
عبارت محتوای الزامی را دریافت یا تنظیم می‌کند.
برای جزئیات بیشتر به git-annex-required(1) مراجعه کنید.
حداکثر اندازه مخزن را دریافت یا تنظیم می‌کند.
یک کلاستر جدید را مقداردهی اولیه می‌کند.
برای جزئیات بیشتر به git-annex-initcluster(1) مراجعه کنید.
سوابق گره‌های کلاستر را به‌روزرسانی می‌کند.
برای جزئیات بیشتر به git-annex-updatecluster(1) مراجعه کنید.
یک درگاه اضافی به یک کلاستر اضافه می‌کند.
برای جزئیات بیشتر به git-annex-extendcluster(1) مراجعه کنید.
سوابق را با پیکربندی پروکسی به‌روزرسانی می‌کند.
برای جزئیات بیشتر به git-annex-updateproxy(1) مراجعه کنید.
وظایف زمان‌بندی‌شده را دریافت یا تنظیم می‌کند.
برای جزئیات بیشتر به git-annex-schedule(1) مراجعه کنید.
سایر تنظیمات پیکربندی ذخیره‌شده در شاخه git-annex را دریافت و تنظیم می‌کند.
برای جزئیات بیشتر به git-annex-config(1) مراجعه کنید.
ویرایشگر EDITOR را روی یک فایل موقت حاوی بیشتر تنظیمات پیکربندی بالا، همراه با چند مورد دیگر باز می‌کند و پس از خروج، هرگونه تغییر ایجادشده را در شاخه git-annex ذخیره می‌نماید.
برای جزئیات بیشتر به git-annex-vicfg(1) مراجعه کنید.
یک مخزن را به استفاده از یک شاخه تعدیل‌شده تغییر می‌دهد، که می‌تواند به طور خودکار قفل تمام فایل‌ها را باز کند و غیره.
برای جزئیات بیشتر به git-annex-adjust(1) مراجعه کنید.
مخزن را به استفاده از حالت مستقیم تغییر می‌دهد. (منسوخ‌شده)
برای جزئیات بیشتر به git-annex-direct(1) مراجعه کنید.
مخزن را به استفاده از حالت غیرمستقیم تغییر می‌دهد. (منسوخ‌شده)
برای جزئیات بیشتر به git-annex-indirect(1) مراجعه کنید.

یکپارچگی ضمیمه را بررسی کرده و درباره هرگونه مشکل یافت‌شده هشدار می‌دهد یا آن را برطرف می‌کند. این دستور مکمل خوبی برای git fsck است.
برای جزئیات بیشتر به git-annex-fsck(1) مراجعه کنید.
مخازنی را که اخیراً فعالیتی (مانند fsck) انجام نداده‌اند، منقضی می‌کند.
برای جزئیات بیشتر به git-annex-expire(1) مراجعه کنید.
ضمیمه را برای داده‌هایی که با هیچ فایلی در هیچ برچسب یا شاخه‌ای مطابقت ندارند بررسی کرده و یک فهرست شماره‌گذاری‌شده از داده‌ها را چاپ می‌کند.
برای جزئیات بیشتر به git-annex-unused(1) مراجعه کنید.
داده‌های مربوط به شماره‌های فهرست‌شده در آخرین خروجی git annex unused را حذف می‌کند.
برای جزئیات بیشتر به git-annex-dropunused(1) مراجعه کنید.
فایل‌ها را برای محتوای مربوط به شماره‌ها یا بازه‌های فهرست‌شده در آخرین خروجی git annex unused مجدداً اضافه می‌کند.
برای جزئیات بیشتر به git-annex-addunused(1) مراجعه کنید.
پیوندهای نمادینی را که خراب شده‌اند اصلاح می‌کند تا دوباره به محتوای ضمیمه‌شده اشاره کنند.
برای جزئیات بیشتر به git-annex-fix(1) مراجعه کنید.
تغییرات را به طور خودکار از مخازن دوردست ادغام می‌کند.
برای جزئیات بیشتر به git-annex-merge(1) مراجعه کنید.
مخزن را ارتقا می‌دهد.
برای جزئیات بیشتر به git-annex-upgrade(1) مراجعه کنید.
مشخص می‌کند که یک مخزن یا یک کلید منفرد به طور جبران‌ناپذیری از دست رفته است.
برای جزئیات بیشتر به git-annex-dead(1) مراجعه کنید.
باعث بازنویسی شاخه git-annex و دور ریختن داده‌های تاریخی مربوط به مکان‌های گذشته فایل‌ها می‌شود.
برای جزئیات بیشتر به git-annex-forget(1) مراجعه کنید.
یک نسخه فیلترشده از شاخه git-annex تولید می‌کند.
برای جزئیات بیشتر به git-annex-filter-branch(1) مراجعه کنید.
این می‌تواند بسیاری از مشکلاتی را که git fsck در مخازن گیت شناسایی می‌کند، اما خودش تعمیر نمی‌کند، برطرف سازد. این دستور زمانی مفید است که یک مخزن به شدت آسیب دیده باشد. یکی از حالت‌هایی که این اتفاق می‌تواند رخ دهد این است که مخزن استفاده‌شده توسط git-annex روی یک درایو جداشدنی قرار داشته باشد که در زمان نامناسبی از سیستم جدا شده باشد.
برای جزئیات بیشتر به git-annex-repair(1) مراجعه کنید.
پیوندهای همتا به همتا (peer-to-peer) را میان مخازن پیکربندی می‌کند.
برای جزئیات بیشتر به git-annex-p2p(1) مراجعه کنید.

فهرستی از فایل‌های ضمیمه‌شده را در مسیر مشخص‌شده خروجی می‌دهد. در صورت نبود مسیر، فایل‌ها را در دایرکتوری جاری و زیردایرکتوری‌های آن پیدا می‌کند.
برای جزئیات بیشتر به git-annex-find(1) مراجعه کنید.
اطلاعاتی درباره مکان قرارگیری محتوای فایل‌ها نمایش می‌دهد.
برای جزئیات بیشتر به git-annex-whereis(1) مراجعه کنید.
جدولی از مخازن دوردست را که حاوی محتوای فایل‌های مشخص‌شده هستند نمایش می‌دهد. این شبیه به whereis است اما خروجی فشرده‌تری دارد.
برای جزئیات بیشتر به git-annex-list(1) مراجعه کنید.
فایل‌هایی را که از یک کلید استفاده می‌کنند یا کرده‌اند پیدا می‌کند.
گزارش مکان را برای فایل یا فایل‌های مشخص‌شده نمایش می‌دهد و نشان می‌دهد که آن‌ها به کدام مخزن اضافه ("+") و از کدام مخزن حذف ("-") شده‌اند.
برای جزئیات بیشتر به git-annex-log(1) مراجعه کنید.
کلیدهای استفاده‌شده برای نسخه‌های قدیمی فایل‌ها را فهرست می‌کند.
برای جزئیات بیشتر به git-annex-oldkeys(1) مراجعه کنید.
آمار و سایر اطلاعات را برای مورد مشخص‌شده نمایش می‌دهد، که می‌تواند یک دایرکتوری، فایل، مخزن دوردست، یا uuid یک مخزن باشد.
هنگامی که موردی مشخص نشده باشد، آمار و اطلاعات مربوط به کل مخزن را نمایش می‌دهد.
برای جزئیات بیشتر به git-annex-info(1) مراجعه کنید.
نسخه git-annex و همچنین اطلاعات نسخه مخزن را نمایش می‌دهد.
برای جزئیات بیشتر به git-annex-version(1) مراجعه کنید.
نقشه‌ای از مخازن تولید می‌کند.
برای جزئیات بیشتر به git-annex-map(1) مراجعه کنید.
دسترسی به فایل‌ها در حین بارگیری آن‌ها.
برای جزئیات بیشتر به git-annex-inprogress(1) مراجعه کنید.
مشابه git-annex find است، اما روی کلیدها عمل می‌کند.
برای جزئیات بیشتر به git-annex-findkeys(1) مراجعه کنید.

محتوای یک فایل ضمیمه‌شده می‌تواند هر تعداد فیلد فراداده (metadata) را برای توصیف خود به همراه داشته باشد. هر فیلد فراداده نیز می‌تواند شامل هر تعداد مقدار باشد.
این دستور می‌تواند برای تنظیم فراداده یا نمایش فراداده‌های فعلی تنظیم‌شده استفاده شود.
برای جزئیات بیشتر به git-annex-metadata(1) مراجعه کنید.
از فراداده برای ساختن یک شاخه نما (view branch) از فایل‌ها در شاخه فعلی استفاده کرده و شاخه نما را تحویل (checkout) می‌گیرد. فقط فایل‌هایی در شاخه فعلی که فراداده آن‌ها با تمام مقادیر فیلد و برچسب‌های مشخص‌شده مطابقت داشته باشد، در نما نشان داده خواهند شد.
برای جزئیات بیشتر به git-annex-view(1) مراجعه کنید.
از نمای فعال فعلی به نمای قبلی بازمی‌گردد؛ یا از نمای نخست به شاخه اصلی بازمی‌گردد.
برای جزئیات بیشتر به git-annex-vpop(1) مراجعه کنید.
نمای فعلی را تنها به فایل‌هایی فیلتر می‌کند که مقادیر فیلد و برچسب‌های مشخص‌شده را دارا باشند.
برای جزئیات بیشتر به git-annex-vfilter(1) مراجعه کنید.
نمای فعلی را تغییر داده و یک سطح اضافی از دایرکتوری‌ها را برای دسته‌بندی فایل‌ها اضافه می‌کند.
برای جزئیات بیشتر به git-annex-vfilter(1) مراجعه کنید.
هنگامی که یک نما شامل زیردایرکتوری‌های تودرتو باشد، ترتیب آن‌ها را به صورت چرخشی تغییر می‌دهد.
برای جزئیات بیشتر به git-annex-vcycle(1) مراجعه کنید.

فایل‌های ضمیمه‌شده مشخص‌شده را برای استفاده از یک بک‌اند کلید-مقدار دیگر تغییر می‌دهد.
برای جزئیات بیشتر به git-annex-migrate(1) مراجعه کنید.
فایل src را به عنوان محتوای فایل dest به درون ضمیمه منتقل می‌کند. این می‌تواند زمانی مفید باشد که محتوای یک فایل را از جای دیگری به دست آورده‌اید و می‌خواهید آن را در ضمیمه محلی قرار دهید.
برای جزئیات بیشتر به git-annex-reinject(1) مراجعه کنید.
از این دستور برای لغو یک دستور ناخواسته یا تصادفی git annex add استفاده کنید. این کار فایل را به حالت قبل از افزودن بازمی‌گرداند.
برای جزئیات بیشتر به git-annex-unannex(1) مراجعه کنید.
لغو مقداردهی اولیه git-annex و پاک‌سازی مخزن.
برای جزئیات بیشتر به git-annex-uninit(1) مراجعه کنید.
مقداردهی اولیه مخزن با استفاده مجدد از UUID قدیمی.
برای جزئیات بیشتر به git-annex-reinit(1) مراجعه کنید.

این دستور برای فراخوانی از قلاب pre-commit گیت در نظر گرفته شده است. دستور git annex init به طور خودکار یک قلاب pre-commit با استفاده از این ایجاد می‌کند.
برای جزئیات بیشتر به git-annex-pre-commit(1) مراجعه کنید.
این دستور برای فراخوانی از قلاب post-receive گیت در نظر گرفته شده است. دستور git annex init به طور خودکار یک قلاب post-receive با استفاده از این ایجاد می‌کند.
برای جزئیات بیشتر به git-annex-post-receive(1) مراجعه کنید.
کلید استفاده‌شده برای یک فایل را جستجو می‌کند.
برای جزئیات بیشتر به git-annex-lookupkey(1) مراجعه کنید.
کلیدی را که برای ارجاع به یک فایل استفاده خواهد شد، محاسبه می‌کند.
برای جزئیات بیشتر به git-annex-calckey(1) مراجعه کنید.
مکان محتوای ضمیمه‌شده را برای یک کلید جستجو می‌کند.
برای جزئیات بیشتر به git-annex-contentlocation(1) مراجعه کنید.
اطلاعاتی را چاپ می‌کند که صرفاً با بررسی کلید قابل تشخیص هستند.
برای جزئیات بیشتر به git-annex-examinekey(1) مراجعه کنید.
بررسی می‌کند که آیا یک عبارت محتوای ترجیحی با داده‌های ارائه‌شده مطابقت دارد یا خیر.
برای جزئیات بیشتر به git-annex-matchexpression(1) مراجعه کنید.
یک فایل را در مخزن گیت به صورت دستی تنظیم می‌کند تا به یک کلید مشخص پیوند داده شود.
برای جزئیات بیشتر به git-annex-fromkey(1) مراجعه کنید.
یک نشانی وب را برای یک کلید ثبت می‌کند.
برای جزئیات بیشتر به git-annex-registerurl(1) مراجعه کنید.
ثبت یک نشانی وب را برای یک کلید لغو می‌کند.
برای جزئیات بیشتر به git-annex-unregisterurl(1) مراجعه کنید.
اطلاعات ثبت نشانی وب را به‌روزرسانی می‌کند.
برای جزئیات بیشتر به git-annex-reregisterurl(1) مراجعه کنید.
یک فایل را به عنوان محتوای یک کلید به درون ضمیمه منتقل می‌کند.
برای جزئیات بیشتر به git-annex-setkey(1) مراجعه کنید.
محتوای ضمیمه‌شده را برای کلیدهای مشخص‌شده حذف می‌کند.
برای جزئیات بیشتر به git-annex-dropkey(1) مراجعه کنید.
یک کلید را از یا به یک مخزن دوردست منتقل می‌کند.
برای جزئیات بیشتر به git-annex-transferkey(1) مراجعه کنید.
به طور داخلی توسط git-annex برای انتقال محتوا استفاده می‌شود.
برای جزئیات بیشتر به git-annex-transferrer(1) مراجعه کنید.
به طور داخلی توسط نسخه‌های قدیمی دستیار استفاده می‌شد.
برای جزئیات بیشتر به git-annex-transferkey(1) مراجعه کنید.
این دستور در سطح زیرساختی (plumbing)، سوابق git-annex را درباره اینکه آیا محتوای کلید مشخص‌شده در یک مخزن دوردست با uuid تعیین‌شده موجود است یا خیر، تغییر می‌دهد.
برای جزئیات بیشتر به git-annex-setpresentkey(1) مراجعه کنید.
سوابق مربوط به مکان‌هایی را که کلید در آن‌ها موجود است می‌خواند.
برای جزئیات بیشتر به git-annex-readpresentkey(1) مراجعه کنید.
بررسی می‌کند که آیا کلید در مخزن دوردست وجود دارد یا خیر.
برای جزئیات بیشتر به git-annex-checkpresentkey(1) مراجعه کنید.
کلیدهای استفاده‌شده برای فایل‌ها را تغییر می‌دهد.
برای جزئیات بیشتر به git-annex-rekey(1) مراجعه کنید.
یک ادغام دارای تداخل را با افزودن هر دو نسخه متعارض فایل به درخت، با استفاده از گونه‌های نام فایل آن‌ها برطرف می‌کند. این کار هنگام استفاده از git annex sync یا git-annex pull یا git annex merge به طور خودکار انجام می‌شود.
برای جزئیات بیشتر به git-annex-resolvemerge(1) مراجعه کنید.
این می‌تواند برای تنظیم git diff جهت مقایسه تفاوت‌های محتوای فایل‌های ضمیمه‌شده به کار رود.
برای جزئیات بیشتر به git-annex-diffdriver(1) مراجعه کنید.
این دستور اجازه می‌دهد تا git-annex به عنوان درایور فیلتر گیت استفاده شود، و بدین ترتیب فایل‌های ضمیمه‌شده در مخزن گیت به جای پیوندهای نمادین، فایل‌های بازشده معمولی باشند.
برای جزئیات بیشتر به git-annex-smudge(1) مراجعه کنید.
یک پیاده‌سازی جایگزین از درایور فیلتر گیت، که در برخی موقعیت‌ها سریع‌تر و در برخی دیگر کندتر از git-annex smudge عمل می‌کند.
برای جزئیات بیشتر به git-annex-filter-process(1) مراجعه کنید.
فایل‌های بازشده را مجدداً در ایندکس گیت آماده (restage) می‌کند.
برای جزئیات بیشتر به git-annex-restage(1) مراجعه کنید.
فایل‌ها را در یک مرجع (ref) گیت فهرست می‌کند. (منسوخ‌شده)
برای جزئیات بیشتر به git-annex-findref(1) مراجعه کنید.
حفاظ حالت مستقیم را دور می‌زند. (منسوخ‌شده)
برای جزئیات بیشتر به git-annex-proxy(1) مراجعه کنید.

مجموعه آزمایش‌های داخلی git-annex را اجرا می‌کند.
برای جزئیات بیشتر به git-annex-test(1) مراجعه کنید.
یک مخزن دوردست را با تولید چند شیء تصادفی و ارسال آن‌ها به مخزن دوردست، سپس بارگیری مجدد، حذف آن‌ها از مخزن دوردست و غیره آزمایش می‌کند.
اجرای آن در یک مخزن موجود ایمن است (محتویات مخزن تغییر نمی‌کند)، اگرچه ممکن است انتقال داده‌های پرهزینه‌ای را انجام دهد.
برای جزئیات بیشتر به git-annex-testremote(1) مراجعه کنید.
این دستور شبکه‌ای از مخازن git-annex را شبیه‌سازی می‌کند. می‌توان از آن برای آزمایش یک پیکربندی پیش از استفاده در دنیای واقعی بهره برد.
برای جزئیات بیشتر به git-annex-sim(1) مراجعه کنید.
تغییرات تصادفی در فایل‌های مخزن جاری ایجاد می‌کند تا برای آزمایش دستیار (assistant) مورد استفاده قرار گیرد.
برای جزئیات بیشتر به git-annex-fuzztest(1) مراجعه کنید.
در صورتی که git-annex با پشتیبانی از معیارسنجی ساخته شده باشد، بنچمارک‌های داخلی آن را اجرا می‌کند.
برای جزئیات بیشتر به git-annex-benchmark(1) مراجعه کنید.

علاوه بر تمامی دستورات ذکر شده در بالا، با قرار دادن دستوراتی با نام‌هایی مانند "git-annex-foo" در پوشه‌ای در PATH، می‌توان دستورات بیشتری را به git-annex اضافه کرد.

مانند سایر دستورات git، ابزار git-annex نیز از طریق .git/config پیکربندی می‌شود. این تنظیمات و همچنین تنظیمات مرتبط در git config، مواردی هستند که git-annex استفاده می‌کند.

(برخی از این تنظیمات را می‌توان با استفاده از git-annex-config در تمام کلون‌های مخزن نیز اعمال کرد. برای مشاهده فهرست آنها به صفحه راهنمای آن مراجعه کنید.)

یک UUID یکتا برای این مخزن (به طور خودکار تنظیم می‌شود).
نام بک‌اند کلید-مقدار پیش‌فرض برای استفاده هنگام افزودن فایل‌های جدید به مخزن. برای اطلاعات درباره بک‌اندهای موجود به git-annex-backends(1) مراجعه کنید.
این مورد توسط پیکربندی annex.backend در فایل‌های .gitattributes و توسط گزینه --backend بازنویسی (override) می‌شود.
(این گزینه قبلاً annex.backends نامیده می‌شد و در صورت تنظیم همچنان استفاده خواهد شد.)
تنظیم روی true نشان می‌دهد که مخزن فقط باید از درهم‌سازهای (هش‌های) امن رمزنگاری‌شده (SHA2, SHA3) استفاده کند و نه هش‌های ناامن (MD5, SHA1) برای محتوا.
هنگامی که این گزینه فعال باشد، اجازه اضافه شدن محتوای فایل‌هایی که از هش‌های رمزنگاری ناامن استفاده می‌کنند به مخزن داده نخواهد شد.
همچنین git-annex fsck در مورد هر فایل موجود در مخزن که از هش‌های ناامن استفاده می‌کند هشدار خواهد داد. و git-annex import --no-content از وارد کردن فایل‌ها از ریموت‌های ویژه با استفاده از هش‌های ناامن خودداری می‌کند.
برای پیکربندی این رفتار در کلون‌های جدید مخزن، می‌توان آن را با استفاده از git-annex-config تنظیم کرد.
حداکثر طول، بر حسب بایت، برای آنچه پسوند نام فایل در نظر گرفته می‌شود. این گزینه هنگام افزودن فایل به بک‌اندی که پسوندهای نام فایل را حفظ می‌کند و همچنین هنگام تولید یک شاخه نما (view branch) استفاده می‌شود.
طول پیش‌فرض ۴ است که پسوندهایی مانند "jpeg" را مجاز می‌داند. نقطه قبل از پسوند جزو طول آن شمرده نمی‌شود.
حداکثر تعداد پسوندهای نام فایل جهت نگهداری هنگام استفاده از بک‌اندی که پسوندهای نام فایل را حفظ می‌کند و همچنین هنگام تولید شاخه نما.
مقدار پیش‌فرض ۲ است که امکان پسوندهای ترکیبی مانند ".tar.gz" را فراهم می‌کند. وقتی روی ۱ تنظیم شود، فقط آخرین پسوند را حفظ می‌کند، مانند ".gz".
میزان فضای دیسک برای رزرو. فضای دیسک هنگام انتقال محتوای پیوست‌شده بررسی می‌شود تا از اتمام فضا جلوگیری شود و می‌توان فضای خالی اضافی را از طریق این گزینه رزرو کرد تا فضایی برای سایر داده‌ها (مانند لاگ‌های کامیت git) باقی بماند. می‌تواند با هر یک از واحدهای رایج مشخص شود، به عنوان مثال "0.5 gb"، "500M" یا "100 KiloBytes".
میزان رزرو پیش‌فرض ۱۰۰ مگابایت است.
درصد پر بودن مخزن را پیکربندی می‌کند تا عبارت محتوای ترجیحی "fullybalanced" آن را پر در نظر بگیرد. مقدار پیش‌فرض ۹۰ است.
تنظیم روی true باعث می‌شود دستوراتی مانند "git-annex get" مواردی را که در خط فرمان ذکر شده‌اند اما در git ثبت نشده‌اند، بدون پیام خطا نادیده بگیرند.
تنظیم روی false باعث می‌شود اگر به دستوراتی مانند "git-annex get" گفته شود روی فایل‌هایی که در git ثبت نشده‌اند عمل کنند، خطا در نظر گرفته شود. (این مقدار پیش‌فرض در نسخه‌های اخیر git-annex است.)
توجه داشته باشید که وقتی annex.skipunknown برابر false است، دستوری مانند "git-annex get ." در صورتی که هیچ فایلی در پوشه جاری در git ثبت نشده باشد با شکست مواجه می‌شود. دستوراتی مانند "git-annex get foo/" در صورتی که هیچ فایلی در پوشه در git ثبت نشده باشد با شکست مواجه می‌شوند، اما اگر حداقل یک فایل ثبت شده باشد، سایر فایل‌هایی را که ثبت نشده‌اند نادیده می‌گیرد. این دقیقاً مشابه رفتار "git-ls files --error-unmatch" است.
همچنین توجه داشته باشید که git-annex فایل‌هایی را که در git ثبت شده‌اند اما فایل پیوست‌شده نیستند نادیده می‌گیرد؛ این تنظیم روی آن تأثیری ندارد.
برای پیکربندی اینکه چه فایل‌هایی به اندازه کافی بزرگ هستند که به annex افزوده شوند استفاده می‌شود. این یک عبارت تطبیق با فایل‌های بزرگ است، مانند "include=*.mp3 or largerthan=500kb". برای جزئیات مربوط به نحو به git-annex-matching-expression(1) مراجعه کنید.
ویژگی‌های annex.largefiles در فایل‌های .gitattributes را لغو می‌کند.
برای پیکربندی یک annex.largefiles پیش‌فرض برای تمام کلون‌های مخزن، می‌توان این مورد را در git-annex-config(1) تنظیم کرد.
این گزینه رفتار هر دو ابزار git-annex و git را هنگام افزودن فایل‌ها به مخزن پیکربندی می‌کند. به طور پیش‌فرض، git-annex add تمام فایل‌ها را به annex اضافه می‌کند (به جز فایل‌های نقطه‌دار و فایل‌های موجود در پوشه‌های نقطه‌دار)، و git add فایل‌ها را به git اضافه می‌کند (مگر اینکه قبلاً به annex اضافه شده باشند). هنگامی که annex.largefiles پیکربندی شده باشد، هم git annex add و هم git add فایل‌های بزرگ منطبق را به annex و سایر فایل‌ها را به git اضافه می‌کنند.
سایر دستورات git-annex نیز به annex.largefiles احترام می‌گذارند، از جمله git annex import، git annex addurl، git annex importfeed، git-annex assist و git-annex assistant.
به طور معمول، فایل‌های نقطه‌دار (dotfiles) و فایل‌های درون پوشه‌های نقطه‌دار به عنوان فایل‌های پیکربندی مانند .gitignore فرض می‌شوند که محتوای آنها همیشه باید بخشی از مخزن git باشد، بنابراین به annex اضافه نمی‌شوند. تنظیم annex.dotfiles روی true باعث می‌شود این فایل‌ها نیز مانند هر فایل دیگری به annex اضافه شوند.
برای پیوست کردن فقط برخی از فایل‌های نقطه‌دار، این گزینه را فعال کنید و annex.largefiles را طوری پیکربندی کنید که با موارد مورد نظرتان مطابقت داشته باشد. برای مثال، برای تطبیق فقط فایل‌های نقطه‌داری که به ".big" ختم می‌شوند:

git config annex.largefiles "(include=.*.big or include=*/.*.big) or (exclude=.* and exclude=*/.*)"
git config annex.dotfiles true
برای پیکربندی یک annex.dotfiles پیش‌فرض برای تمامی کلون‌های مخزن، می‌توان این مورد را در git-annex-config(1) تنظیم کرد.
تنظیم این گزینه روی false مانع از اضافه شدن فایل‌ها توسط git add به annex، علیرغم پیکربندی annex.largefiles می‌شود.
کنترل می‌کند که آیا فایل‌های کوچک (فایل‌هایی که با annex.largefiles مطابقت ندارند، یا فایل‌های نقطه‌دار) باید توسط git annex add در git ثبت شوند یا خیر. پیش‌فرض true است؛ برای نادیده گرفتن فایل‌های کوچک، آن را روی false تنظیم کنید.
دستوراتی مانند git-annex add به طور پیش‌فرض فایل‌ها را به صورت قفل‌شده به مخزن اضافه می‌کنند. این گزینه می‌تواند باعث شود آنها فایل‌ها را به صورت قفل‌گشایی‌شده اضافه کنند، همان‌گونه که اگر git-annex-unlock(1) روی فایل‌ها اجرا می‌شد.
می‌توان این مورد را روی "true" تنظیم کرد تا همه‌چیز به صورت قفل‌گشایی‌شده اضافه شود، یا می‌تواند یک عبارت پیچیده‌تر باشد که فایل‌ها را بر اساس نام، اندازه یا محتوا تطبیق دهد. برای جزئیات به git-annex-matching-expression(1) مراجعه کنید.
برای پیکربندی یک annex.addunlocked پیش‌فرض برای تمام کلون‌های مخزن، می‌توان این مورد را در git-annex-config(1) تنظیم کرد.
استفاده از git add همیشه فایل‌ها را به صورت قفل‌گشایی‌شده اضافه می‌کند و تحت تأثیر این تنظیم قرار نمی‌گیرد. دستیار (assistant) به طور پیش‌فرض همه فایل‌ها را قفل‌گشایی‌شده اضافه می‌کند، مگر اینکه annex.assistant.allowunlocked تنظیم شده باشد.
هنگامی که یک مخزن core.symlinks را روی false تنظیم کرده باشد، یا یک شاخه قفل‌گشایی‌شده تنظیم‌شده (adjusted unlocked branch) را checkout کرده باشد، این تنظیم نادیده گرفته می‌شود و فایل‌ها همیشه به صورت قفل‌گشایی‌شده به مخزن اضافه می‌شوند.
دستیار git-annex assistant به طور پیش‌فرض همه فایل‌ها را به صورت قفل‌گشایی‌شده اضافه می‌کند، به طوری که فایل‌ها بتوانند بدون نیاز به انجام کاری توسط کاربر برای باز کردن قفل، ویرایش شوند.
اگر این مقدار روی true تنظیم شود، در عوض از پیکربندی annex.addunlocked برای تصمیم‌گیری در مورد اینکه کدام فایل‌ها به صورت قفل‌گشایی‌شده اضافه شوند استفاده خواهد کرد.
این یک تنظیم منسوخ‌شده است. در عوض باید از دستور git annex numcopies برای پیکربندی تعداد نسخه‌هایی از فایل‌ها که در سراسر مخازن نگهداری می‌شوند، یا از تنظیم annex.numcopies در .gitattributes استفاده کنید.
این تنظیم پیکربندی فقط زمانی بررسی می‌شود که git annex numcopies هرگز پیکربندی نشده باشد و هیچ تنظیم annex.numcopies در فایل .gitattributes وجود نداشته باشد.
این گزینه را روی true تنظیم کنید تا git-annex هنگام افزودن فایل‌ها به مخزن، مقداری متادیتا را به طور خودکار تولید کند.
به ویژه، متادیتای سال، ماه و روز را بر اساس تاریخ تغییر فایل ذخیره می‌کند.
هنگامی که importfeed استفاده می‌شود، متادیتای اضافی را از فید ذخیره می‌کند، مانند نویسنده، عنوان و غیره.
کنترل می‌کند که git-annex unused کدام refها را به عنوان استفاده‌شده در نظر بگیرد. برای جزئیات به بخش REFSPEC FORMAT در git-annex-unused(1) مراجعه کنید.
تعداد وظایف همزمان برای اجرا را پیکربندی می‌کند. پیش‌فرض ۱ است.
فقط دستورات git-annex که از گزینه --jobs پشتیبانی می‌کنند از این تنظیم استفاده خواهند کرد.
تنظیم این مقدار روی "cpus" به ازای هر هسته پردازنده (CPU) یک وظیفه را اجرا می‌کند.
هنگامی که گزینه --batch استفاده شود، این پیکربندی نادیده گرفته می‌شود.
هنگامی که git-annex-adjust(1) برای راه‌اندازی یک شاخه تنظیم‌شده (adjusted branch) که پس از دریافت یا رها کردن (drop) فایل‌ها نیاز به تازه‌سازی دارد استفاده می‌شود، این پیکربندی کنترل می‌کند که شاخه هر چند وقت یک‌بار تازه‌سازی شود.
تازه‌سازی شاخه زمان می‌برد، بنابراین انجام آن پس از هر فایل می‌تواند بسیار کند باشد. (همچنین می‌تواند اشیای معلق زیادی در git ایجاد کند.) مقدار پیش‌فرض 0 (یا false) است که شاخه را تازه‌سازی نمی‌کند. تنظیم 1 (یا true) تنها یک بار پس از انجام سایر تغییرات توسط git-annex تازه‌سازی می‌کند. مقدار 2 پس از هر فایل، 3 پس از هر دو فایل و به همین ترتیب تازه‌سازی می‌کند؛ مقدار 100 پس از هر 99 فایل تازه‌سازی می‌کند.
(اگر git-annex در آینده سریع‌تر شود، نرخ‌های تازه‌سازی متناسب با بهبود سرعت افزایش می‌یابد.)
ابزار git-annex برای ادغام دستورات مشابه جهت افزایش سرعت، صفی از دستورات git می‌سازد. به طور پیش‌فرض اندازه صف به ۱۰۲۴۰ دستور محدود شده است؛ از این گزینه می‌توان برای تغییر اندازه استفاده کرد. اگر حافظه زیادی دارید و با تعداد بسیار زیادی از فایل‌ها کار می‌کنید، افزایش اندازه صف می‌تواند سرعت آن را بالا ببرد.
دستورات git annex unused و git annex sync --content از یک فیلتر بلوم برای تعیین اینکه چه فایل‌هایی برای مثال در درخت کاری حضور دارند استفاده می‌کنند. اندازه پیش‌فرض فیلتر بلوم برای مدیریت حداکثر ۵۰۰٬۰۰۰ فایل تعیین شده است. اگر مخزن شما بزرگتر از این است، باید این مقدار را افزایش دهید. مقادیر بزرگتر باعث مصرف حافظه بیشتر توسط git-annex unused و git annex sync --content می‌شود؛ برای مشاهده ارقام مصرف حافظه دستور git annex info را اجرا کنید.
دقت فیلتر بلوم مورد استفاده توسط git annex unused و git annex sync --content را تنظیم می‌کند. دقت پیش‌فرض 10000000 است -- ۱ فایل استفاده‌نشده از هر ۱۰٬۰۰۰٬۰۰۰ فایل توسط git annex unused نادیده گرفته خواهد شد. افزایش دقت باعث مصرف حافظه بیشتر توسط git annex unused خواهد شد؛ برای دیدن ارقام مصرف حافظه، git annex info را اجرا کنید.
به طور پیش‌فرض، git-annex اتصالات ssh را با استفاده از تنظیمات ControlMaster و ControlPersist در ssh ذخیره موقت (کَش) می‌کند (در صورتی که با نسخه‌ای به اندازه کافی جدید از ssh ساخته شده باشد). برای غیرفعال کردن این ویژگی، آن را روی false تنظیم کنید.
هنگامی که git-annex قادر به استفاده از کَش اتصالات ssh نیست، یا طوری پیکربندی شده که از آن استفاده نکند، و همزمانی فعال است، هشدار می‌دهد که این ممکن است منجر به درخواست همزمان گذرواژه توسط چندین فرآیند ssh شود. برای غیرفعال کردن این هشدار، برای مثال اگر خودتان کَش اتصال ssh را پیکربندی کرده‌اید یا ssh-agent گذرواژه‌ها را در حافظه دارد، این گزینه را روی false تنظیم کنید.
به طور پیش‌فرض، git-annex پس از اجرای هر دستور، داده‌ها را به طور خودکار به شاخه git-annex کامیت می‌کند. اگر مجموعه‌ای از دستورات دارید که می‌خواهید یک کامیت واحد ایجاد کنند، می‌توانید دستورات را با -c annex.alwayscommit=false اجرا کنید. بعداً می‌توانید با اجرای git annex merge (یا با ادغام‌های خودکار) یا git annex sync داده‌ها را کامیت کنید.
هنگامی که git-annex شاخه git-annex را به‌روزرسانی می‌کند، معمولاً پیام کامیت مخصوص به خود را می‌سازد (مثلاً "update")، زیرا کاربران به ندرت به تغییرات آن شاخه نگاه کرده یا اهمیت می‌دهند. اگر این موضوع برای شما مهم است، می‌توانید با اجرای دستورات به همراه -c annex.commitmessage=whatever این تنظیم را مشخص کنید.
این گزینه در ترکیب با annex.alwayscommit=false به خوبی کار می‌کند تا مجموعه‌ای از تغییرات را گردآوری کرده و آنها را با پیامی که مشخص می‌کنید کامیت کند.
این دستور اجرا شده و خروجی آن به عنوان پیام کامیت برای شاخه git-annex استفاده می‌شود.
همچنین می‌توان یک اسکریپت قلاب (hook) در .git/hooks/commitmessage-annex نصب کرد.
این دستور پس از اینکه git-annex شاخه git-annex را به‌روزرسانی کرد، اجرا می‌شود.
هنگام انتشار یک مخزن git-annex از طریق http، می‌توان از این گزینه برای اجرای git update-server-info استفاده کرد.
همچنین می‌توان یک اسکریپت قلاب در .git/hooks/post-update-annex نصب کرد.
این دستور هر زمان که کامیتی در شاخه HEAD مخزن git ایجاد شود (چه توسط git commit یا توسط git-annex) اجرا می‌شود.
همچنین می‌توان یک اسکریپت قلاب در .git/hooks/pre-commit-annex نصب کرد.
این دستور قبل از مقداردهی اولیه مخزن، چه توسط git-annex init و چه با مقداردهی اولیه خودکار، اجرا می‌شود. می‌تواند مخزن را به هر روشی که لازم است پیکربندی کند. اگر با خروجی غیرصفر خارج شود، مقداردهی اولیه مخزن با شکست مواجه خواهد شد.
همچنین می‌توان یک اسکریپت قلاب در .git/hooks/pre-init-annex نصب کرد.
به طور پیش‌فرض، git-annex داده‌هایی را که در شاخه git-annex ثبت می‌کند فشرده‌سازی (compact) می‌نماید. تنظیم این مقدار روی false در برخی موارد از این فشرده‌سازی جلوگیری می‌کند، که می‌تواند عملیاتی را که شاخه git-annex را با داده‌های زیاد پر می‌کنند سرعت ببخشد. با این حال، هنگام استفاده با عملیاتی که مقادیر قدیمی را در شاخه git-annex بازنویسی می‌کنند، ممکن است باعث شود شاخه git-annex فضای دیسک بیشتری مصرف کند و بنابراین خواندن داده‌ها از آن کندتر شود.
نمونه‌ای از دستوری که با استفاده از -c annex.alwayscompact=false سرعت آن افزایش می‌یابد، git-annex registerurl --batch هنگام افزودن تعداد زیادی URL به یک کلید یکسان است.
این گزینه برای اولین بار در نسخه 10.20220724 برنامه git-annex پشتیبانی شد. تنظیم این گزینه در مخزنی که ممکن است همزمان توسط نسخه قدیمی‌تر git-annex و نسخه‌ای که از این گزینه پشتیبانی می‌کند استفاده شود، کاملاً ایمن نیست.
به طور پیش‌فرض git-annex از امضای gpg برای کامیت‌هایی که هدف اصلی یک دستور نیستند و صرفاً یک اثر جانبی محسوب می‌شوند، خودداری می‌کند. این پیش‌فرض از درخواست‌های مکرر گذرواژه gpg در صورت تنظیم commit.gpgSign جلوگیری می‌کند. دستوری مانند git annex sync یا git annex merge کامیت خود را با gpg امضا خواهد کرد، اما دستوری مانند git annex get که شاخه git-annex را به‌روزرسانی می‌کند، این کار را انجام نخواهد داد. دستیار (assistant) نیز از امضای کامیت‌ها خودداری می‌کند.
تنظیم annex.allowsign روی true امکان امضای تمام کامیت‌ها را طبق تنظیمات commit.gpgSign و سایر پیکربندی‌های git فراهم می‌کند.
به طور پیش‌فرض، شاخه‌های git-annex که از ریموت‌ها دریافت (pull) شده‌اند، به طور خودکار در شاخه محلی git-annex ادغام می‌شوند تا git-annex به‌روزترین اطلاعات ممکن را در اختیار داشته باشد.
برای جلوگیری از این ادغام، این گزینه را روی "false" تنظیم کنید.
این می‌تواند به ویژه زمانی مفید باشد که مجوز نوشتن در مخزن را ندارید. اگرچه git-annex بیشتر قادر است در یک مخزن فقط‌خواندنی با شاخه‌های ادغام‌نشده git-annex کار کند، برخی موارد کار نمی‌کنند و زمانی هم که کار کند، به دلیل نیاز به بررسی هر یک از شاخه‌های ادغام‌نشده کندتر خواهد بود.
هنگامی که این گزینه روی true تنظیم شود، هیچ اطلاعاتی در مورد مخزن در شاخه git-annex ثبت نخواهد شد.
برای مثال، برای ساخت مخزنی بدون اینکه هرگز نامی از آن در شاخه git-annex ظاهر شود:

git init myprivate
cd myprivaterepo
git config annex.private true
git annex init
این گزینه را روی true تنظیم کنید تا در صورت امکان، محتوای فایل‌ها به جای یک کپی پرهزینه‌تر، بین مخزن و ریموت‌های آن پیوند سخت (hard link) شود.
با احتیاط استفاده شود -- این می‌تواند شمارش numcopies را باطل کند، زیرا با پیوندهای سخت، نسخه‌های کمتری از یک فایل ممکن است وجود داشته باشد. بنابراین، ایده خوبی است که مخزنی را که از این تنظیم استفاده می‌کند به عنوان غیرقابل اعتماد (untrusted) علامت‌گذاری کنید.
هنگامی که یک مخزن با استفاده از git clone --shared راه‌اندازی می‌شود، git-annex init به طور خودکار annex.hardlink را تنظیم کرده و مخزن را به عنوان غیرقابل اعتماد علامت‌گذاری می‌کند.
هنگامی که annex.thin نیز تنظیم شده باشد، تنظیم annex.hardlink هیچ تأثیری ندارد.
این گزینه را روی true تنظیم کنید تا فایل‌های قفل‌گشایی‌شده به جای یک نسخه کپی دوم، یک پیوند سخت به محتوای خود در annex باشند. این می‌تواند مقدار قابل توجهی در فضای دیسک صرفه‌جویی کند، اما هنگامی که تغییری در یک فایل ایجاد می‌شود، نسخه قدیمی محلی (و احتمالاً تنها نسخه) را از دست خواهید داد. هر فایل قفل‌شده دیگری در مخزن که به آن محتوا اشاره می‌کرد نیز خراب می‌شود (git-annex fsck پس از آن، این مورد را شناسایی و پاکسازی خواهد کرد). بنابراین این گزینه را با احتیاط فعال کنید.
پس از تنظیم (یا لغو تنظیم) این مورد، باید git annex fix را اجرا کنید تا فایل‌های پیوست‌شده در درخت کاری اصلاح شده و به پیوندهای سخت (یا کپی‌ها) تبدیل شوند.
توجه داشته باشید که وقتی سیستم فایل از پیوندهای سخت پشتیبانی نمی‌کند، این مورد هیچ اثری ندارد. و هنگامی که چندین فایل در درخت کاری دارای محتوای یکسان باشند، فقط یکی از آنها به annex پیوند سخت می‌شود.
به طور پیش‌فرض git-annex از فایل‌های قفل‌گشایی‌شده و همچنین فایل‌های قفل‌شده پشتیبانی می‌کند، بنابراین این مقدار به طور پیش‌فرض true است. اگر روی false تنظیم شود، git-annex فقط از فایل‌های قفل‌شده پشتیبانی خواهد کرد. این کار از انجام کارهای لازم برای پشتیبانی از فایل‌های قفل‌گشایی‌شده جلوگیری می‌کند.
توجه داشته باشید که تنظیم این گزینه روی false مانع از اضافه شدن فایل‌های قفل‌گشایی‌شده به مخزن نمی‌شود و در این حالت تا زمانی که قفل نشوند، محتوای فایل‌ها قابل دسترسی نخواهد بود.
پس از تغییر این پیکربندی، برای اعمال آن باید git-annex init را دوباره اجرا کنید.
هنگامی که این گزینه روی نام یک ریموت تنظیم شود، فایل‌هایی که از مخزن رها (drop) می‌شوند به آن ریموت منتقل خواهند شد.
توجه داشته باشید اگر انتقال فایل به ریموت زمان زیادی ببرد، کاربر نمایشی از پیشرفت برای عملیات drop خود مشاهده نخواهد کرد. بنابراین بهتر است با یک ریموت سریع استفاده شود.
همچنین اگر ریموت در دسترس نباشد یا انتقال فایل به آن با شکست مواجه شود، فایل از مخزن رها نخواهد شد.
هنگامی که یک ریموت دارای یک URL با پروتکل http باشد، اولین باری که git-annex از ریموت استفاده می‌کند بررسی می‌نماید که آیا می‌تواند فایل .git/config آن را بارگیری کند یا خیر. اگر بتواند و فایل دارای این تنظیم روی یک URL به صورت "annex+http" یا "annex+https" باشد، آن URL در remote.<name>.annexUrl کپی خواهد شد.
تنظیم روی false از حل خودکار تداخل‌های ادغام (merge conflicts) در شاخه فعلی توسط git-annex assistant، git-annex assist، git-annex sync، git-annex pull، git-annex merge و قلاب post-receive برنامه git-annex جلوگیری می‌کند.
برای پیکربندی این رفتار در تمام کلون‌های مخزن، می‌توان این مورد را در git-annex-config(1) تنظیم کرد.
تنظیم روی true باعث می‌شود git-annex sync به طور پیش‌فرض محتوای پیوست‌شده را انتقال دهد.
تنظیم روی false از انتقال محتوای پیوست‌شده توسط git-annex assist، git-annex pull و git-annex push جلوگیری می‌کند.
برای پیکربندی این رفتار در تمام کلون‌های مخزن، می‌توان این مورد را در git-annex-config(1) تنظیم کرد.
تنظیم روی true باعث می‌شود git-annex assist، git-annex sync، git-annex pull و git-annex push به طور پیش‌فرض فقط روی شاخه git-annex و محتوای پیوست‌شده عمل کنند.
برای پیکربندی این رفتار در تمام کلون‌های مخزن، می‌توان این مورد را در git-annex-config(1) تنظیم کرد.
تنظیم روی false مانع از این می‌شود که git-annex sync و git-annex pull مهاجرت‌ها را پویش کرده و مخزن محلی را برای آن مهاجرت‌ها به‌روز کنند.
این گزینه نام پوشه‌ای را پیکربندی می‌کند که در یک نما (view) برای نگهداری فایل‌هایی که متادیتای تنظیم‌شده ندارند استفاده می‌شود. نام پیش‌فرض این پوشه "_" است. برای جزئیات به git-annex-view(1) مراجعه کنید.
تنظیم روی true برای فعال کردن ثبت لاگ‌های اشکال‌زدایی (debug) به صورت پیش‌فرض.
برای پیکربندی اینکه کدام پیام‌های اشکال‌زدایی نمایش داده شوند (هنگامی که نمایش پیام اشکال‌زدایی توسط annex.debug یا --debug فعال شده است) تنظیم می‌شود. مقدار آن یک یا چند نام ماژول است که با کاما از هم جدا شده‌اند.
نسخه فعلی مخزن git-annex. این مورد توسط git-annex نگهداری می‌شود و هرگز نباید به صورت دستی تغییر کند.
هنگامی که یک نسخه قدیمی از مخزن git-annex دیگر پشتیبانی نمی‌شود، git-annex به طور معمول مخزن را به طور خودکار به نسخه جدید ارتقا می‌دهد. همچنین ممکن است گاهی از یک نسخه قدیمی مخزن که هنوز پشتیبانی می‌شود اما به خوبی نسخه جدیدتر نیست، ارتقا یابد.
اگر این مقدار روی false تنظیم شود، git-annex مخزن را به طور خودکار ارتقا نخواهد داد. اگر نسخه مخزن پشتیبانی نشود، git-annex در عوض با یک پیام خطا خارج می‌شود. اگر هنوز پشتیبانی شود، git-annex به کار خود ادامه خواهد داد.
زمانی که آماده ارتقای مخزن شدید، می‌توانید خودتان git annex upgrade را اجرا کنید.
اگر مخزن روی یک سیستم فایل ناقص (crippled filesystem) مانند FAT قرار دارد که از پیوندهای نمادین، پیوندهای سخت یا مجوزهای یونیکس پشتیبانی نمی‌کند، روی true تنظیم کنید. این مورد توسط "git annex init" به صورت خودکار شناسایی و بررسی می‌شود.
به طور معمول، git-annex از فایل‌های قفل‌گذاری دقیق (fine-grained lock files) استفاده می‌کند تا به چندین فرآیند اجازه دهد به صورت همزمان بدون تداخل با یکدیگر اجرا شوند. این به خوبی کار می‌کند، مگر اینکه از git-annex روی سیستم فایلی استفاده کنید که از قفل‌های fcntl در استاندارد POSIX پشتیبانی نمی‌کند. این موضوع گاهی اوقات هنگام استفاده از سیستم‌های فایل NFS یا Lustre رخ می‌دهد.
برای پشتیبانی از چنین شرایطی، می‌توانید annex.pidlock را روی true تنظیم کنید و به یک قفل تک‌فایلی pid در بالاترین سطح بازخواهد گشت.
اگرچه در بیشتر موارد واقعاً بهتر است پیکربندی سیستم فایل شبکه‌ای خود را طوری اصلاح کنید که از قفل‌های POSIX پشتیبانی کند.. و همچنین برخی از سیستم‌های فایل شبکه‌ای آن‌قدر ناهماهنگ هستند که یک گره نمی‌تواند به طور قابل اعتمادی تشخیص دهد گره دیگر چه زمانی قفل pid را در اختیار دارد. مسئولیت ریسک با خودتان است (Caveat emptor).
ابزار git-annex تا این تعداد ثانیه منتظر می‌ماند تا فایل قفل pid ناپدید شود و در صورت عدم امکان ادامه کار، عملیات را لغو می‌کند. مقدار پیش‌فرض: ۳۰۰
هنگام استفاده از فایل‌های قفل pid، این احتمال وجود دارد که یک فایل قفل کهنه (stale) از اجرای قبلی git-annex که متوقف یا مختل شده است باقی بماند. از این حالت عمدتاً جلوگیری می‌شود، اما می‌تواند به ویژه هنگام استفاده از یک سیستم فایل شبکه‌ای رخ دهد. این زمان انقضا (timeout) مانع از انتظار همیشگی git-annex در چنین شرایطی می‌شود.
پوشه‌ای که git-annex باید پایگاه‌های داده sqlite خود را در آن ذخیره کند. مکان پیش‌فرض درون .git/annex/ است.
برخی سیستم‌های فایل، مانند cifs، ممکن است از عملیات قفل‌گذاری که sqlite به آن نیاز دارد پشتیبانی نکنند و تنظیم این گزینه روی پوشه‌ای در سیستم فایل دیگر می‌تواند این مشکل را دور بزند.
می‌توان این مورد را در پیکربندی چندین مخزن با اطمینان روی یک پوشه یکسان تنظیم کرد؛ هر مخزن از یک زیرپوشه برای پایگاه داده sqlite خود استفاده خواهد کرد.
هنگامی که روی "true" باشد (پیش‌فرض)، git-annex اطلاعات هویتی و اعتبارسنجی مورد استفاده برای دسترسی به ریموت‌های ویژه را در فایل‌هایی در .git/annex/creds/ که فقط شما می‌توانید بخوانید کَش می‌کند. برای غیرفعال کردن این ذخیره‌سازی، آن را روی "false" تنظیم کنید و اطلاعات اعتبارسنجی فقط از متغیرهای محیطی خوانده می‌شوند یا در صورتی که به صورت رمزگذاری‌شده در مخزن git تعبیه شده باشند، هر بار که git-annex نیاز به دسترسی به ریموت داشته باشد استخراج و رمزگشایی خواهند شد.
می‌توان این گزینه را روی دستوری تنظیم کرد که باید هر زمان که git-annex محتوای یک فایل را از مخزن حذف می‌کند، اجرا شود.
در خط فرمان، %file با فایلی که باید پاک شود جایگزین می‌گردد.
به عنوان مثال، برای استفاده از دستور wipe، آن را روی wipe -f %file تنظیم کنید.
به جای تنظیم در git config، می‌توان یک اسکریپت قلاب را در .git/hooks/secure-erase-annex نصب کرد. فایلی که باید پاک شود به عنوان تنها پارامتر به قلاب داده می‌شود.
معمولاً بیت‌های مجوز نوشتن برای محافظت از اشیای پیوست‌شده در برابر تغییر یا حذف برداشته می‌شوند. Freezecontent پس از اینکه git-annex بیت نوشتن را حذف کرد (یا برای حذف آن تلاش نمود) اجرا می‌شود و می‌تواند برای جلوگیری از نوشتن به روش دیگری استفاده شود. Thawcontent باید اثر آن را خنثی کند و قبل از اینکه git-annex بیت نوشتن را بازیابی کند اجرا می‌شود.
در خط فرمان، %path با فایل یا پوشه‌ای که باید روی آن عملیات انجام شود جایگزین می‌گردد.
(هنگامی که annex.crippledfilesystem تنظیم شده باشد، git-annex تلاشی برای حذف/بازیابی بیت نوشتن نمی‌کند، اما همچنان freezecontent و thawcontent را اجرا خواهد کرد.)
به جای تنظیم در git config، می‌توان اسکریپت‌های قلاب را در .git/hooks/freezecontent-annex و .git/hooks/thawcontent-annex نصب کرد. فایل یا پوشه‌ای که باید روی آن عملیات انجام شود به عنوان تنها پارامتر به قلاب داده می‌شود.
این موارد را می‌توان برای تنظیم دقیق مخزن به git annex init ارسال کرد. تغییر آنها در یک مخزن فعال ایمن نیست و هرگز نباید در پیکربندی سراسری git تنظیم شوند. برای جزئیات به https://git-annex.branchable.com/tuning مراجعه کنید.
این گزینه برای تبدیل مخزن به یک درگاه (gateway) به یک کلاستر تنظیم می‌شود. مقدار آن UUID کلاستر است. توجه داشته باشید که UUIDهای کلاستر با UUIDهای مخزن یکسان نیستند و نمی‌توان از UUID مخزن در اینجا استفاده کرد.
معمولاً این مورد با اجرای git-annex-initcluster یا git-annex-extendcluster راه‌اندازی می‌شود.

ریموت‌ها با استفاده از این تنظیمات در .git/config پیکربندی می‌شوند.

هنگام تعیین اینکه فایل‌های پیوست‌شده از یا به کدام مخزن انتقال یابند، مخازنی با هزینه کمتر ترجیح داده می‌شوند. هزینه پیش‌فرض برای مخازن محلی ۱۰۰ و برای مخازن دوردست (remote) ۲۰۰ است.
در صورت تنظیم، این دستور اجرا شده و عددی که در خروجی می‌دهد به عنوان هزینه استفاده می‌شود. این امر اجازه می‌دهد هزینه بر اساس مواردی مانند شبکه فعلی تغییر کند.
دستوری که هنگام شروع استفاده git-annex از ریموت اجرا می‌شود. از این دستور می‌توان به عنوان مثال برای سوار کردن (mount) پوشه حاوی ریموت استفاده کرد.
هنگامی که چندین فرآیند git-annex به صورت همزمان در حال اجرا هستند، این دستور ممکن است به دفعات مکرر اجرا شود.
دستوری که پس از اتمام استفاده git-annex از ریموت اجرا می‌شود.
این دستور تنها زمانی اجرا خواهد شد که *تمامی* فرآیندهای در حال اجرای git-annex کار با ریموت را به پایان رسانده باشند.
به جای جستجو برای "git-annex-shell" در PATH، یک فایل اجرایی جایگزین برای git-annex-shell در سیستم دوردست مشخص می‌کند.
این گزینه در صورتی مفید است که برنامه git-annex-shell خارج از PATH قرار داشته باشد یا دارای نامی غیر استاندارد باشد.
اگر روی true تنظیم شود، به طور پیش‌فرض از ذخیره یا بازیابی محتوای فایل‌های پیوست‌شده در این ریموت توسط git-annex جلوگیری می‌کند. (هنوز می‌توانید با گزینه‌های --from و --to درخواست استفاده از آن را بدهید.)
این گزینه برای مثال زمانی مفید است که ریموت در جایی قرار دارد که فاقد git-annex-shell است. (به عنوان مثال اگر روی GitHub باشد). یا در صورتی که اتصال شبکه بین دو مخزن برای استفاده عادی بیش از حد کند باشد، می‌تواند استفاده شود.
این تنظیم مانع از کارکرد git-annex sync، git-annex pull، git-annex push، git-annex assist یا git-annex assistant روی مخزن git نمی‌شود؛ فقط روی محتوای پیوست‌شده تأثیر می‌گذارد.
در صورت تنظیم، این دستور اجرا می‌شود و اگر با وضعیت غیرصفر خارج شود، مشابه تنظیم annex-ignore روی true است. این امکان کنترل رفتار را بر اساس مواردی مانند شبکه فعلی فراهم می‌سازد.
اگر روی false تنظیم شود، از کارکرد git-annex sync (و git-annex pull، git-annex push، git-annex assist و git-annex assistant) روی این ریموت به طور پیش‌فرض جلوگیری می‌کند.
در صورت تنظیم، این دستور اجرا می‌شود و اگر با وضعیت غیرصفر خارج شود، مشابه تنظیم annex-sync روی false است. این امکان کنترل رفتار را بر اساس مواردی مانند شبکه فعلی فراهم می‌سازد.
اگر روی false تنظیم شود، از pull (یا دریافت) کردن git-annex pull، git-annex sync، git-annex assist و git-annex assistant از این ریموت به طور کامل جلوگیری می‌کند.
اگر روی false تنظیم شود، از push کردن git-annex push، git-annex sync، git-annex assist و git-annex assistant به این ریموت به طور کامل جلوگیری می‌کند.
اگر روی true تنظیم شود، از اعمال هرگونه تغییر توسط git-annex روی یک ریموت جلوگیری می‌کند. این تنظیم مانع از ارسال (push) تغییرات توسط git-annex sync و git-annex assist به یک مخزن git می‌شود. همچنین از ذخیره‌سازی یا حذف فایل‌ها از ریموت فقط‌خواندنی جلوگیری می‌نماید.
به طور پیش‌فرض، git-annex چِک‌سام‌های اشیای بارگیری‌شده از ریموت‌ها را اعتبارسنجی می‌کند. اگر به یک ریموت اعتماد دارید و سربار ناشی از این بررسی چِک‌سام‌ها را نمی‌خواهید، می‌توانید این گزینه را روی false تنظیم کنید.
توجه داشته باشید که حتی زمانی که این گزینه روی false تنظیم شده باشد، git-annex در برخی شرایط خاص (مانند حالتی که احتمال دارد شیء به صورت نادرست بارگیری شده باشد، یا در صورت نیاز برای امنیت) اعتبارسنجی را انجام می‌دهد.
برای بهینه‌سازی کپی کردن فایل‌ها به/از یک ریموت، روی "true" تنظیم کنید.
تنظیم این گزینه به cp اجازه می‌دهد از فراخوان سیستمی copy_file_range استفاده کند (در صورتی که دستور cp از آن پشتیبانی کند). میزان مزیت به سیستم فایل بستگی دارد. برای مثال در NFS این می‌تواند اجازه دهد یک کپی سمت سرور انجام شود. در ext4 این مورد از برخی سربارهای انتقال حافظه جلوگیری می‌کند، اما فایل همچنان باید کپی شود. در btrfs مزیتی ندارد، زیرا git-annex به طور پیش‌فرض پیوند مجدد CoW با همان سرعت را در btrfs انجام می‌دهد.
این گزینه در صورتی که git-annex نیاز به خواندن فایل کپی‌شده به منظور اعتبارسنجی آن داشته باشد، کمک چندانی به بهبود سرعت کپی نخواهد کرد. بنابراین برای حداکثر سرعت، علاوه بر تنظیم این گزینه، remote.<name>.annex-verify یا annex.verify را روی false قرار دهید.
در حال حاضر تنظیم این گزینه از ادامه کپی‌های متوقف‌شده از جایی که رها شده‌اند جلوگیری می‌کند؛ یک کپی متوقف‌شده دوباره از ابتدا اجرا خواهد شد.
این گزینه برای استفاده با ریموت‌های ویژه است که از صادرات (export) و واردات (import) پشتیبانی می‌کنند.
هنگامی که مثلاً روی "master" تنظیم شود، به git-annex می‌گوید که می‌خواهید ریموت ویژه آن شاخه را دنبال (track) کند.
هنگامی که مثلاً روی "master:subdir" تنظیم شود، ریموت ویژه فقط زیرپوشه آن شاخه را دنبال می‌کند.
تنظیم این گزینه به برخی دستورات دیگر امکان کار با این ریموت‌های ویژه را می‌دهد: دستور git-annex pull تغییرات را از ریموت وارد کرده و آنها را در annex-tracking-branch ادغام می‌کند. و git-annex push تغییرات را به ریموت صادر می‌کند. دستورات سطح بالاتر شامل git-annex sync --content و git-annex assist هم واردات و هم صادرات را انجام می‌دهند.
نام منسوخ‌شده برای remote.<name>.annex-tracking-branch. چنانچه این گزینه پیکربندی شده باشد و remote.<name>.annex-tracking-branch تنظیم نشده باشد، همچنان استفاده خواهد شد.
می‌تواند برای مشخص کردن یک url متفاوت از remote.<name>.url معمولی به کار رود تا git-annex برای دسترسی به ریموت از آن استفاده کند؛ مشابه pushUrl مورد استفاده توسط git-push.
هنگامی که این گزینه روی یک نشانی annex+http یا annex+https تنظیم شود، آن url فقط برای عملیات git-annex استفاده می‌شود و از remote.<name>.url برای عملیات گیت استفاده خواهد شد. این کار اجازه می‌دهد با استفاده از git-annex-p2phttp یک مخزن git-annex را از طریق http سرویس‌دهی کرد.
هنگامی که این گزینه و remote.<name>.url شامل یک نام میزبان یکسان باشند، و این گزینه یک نشانی annex+http(s) و آن یکی نیز یک نشانی http(s) باشد، git-annex فرض می‌کند که می‌توان از همان نام کاربری و گذرواژه برای هر دو url استفاده کرد. هنگامی که حافظه موقت گذرواژه پیکربندی شده باشد، این امکان فراهم می‌شود که در هنگام استفاده هم‌زمان از git و git-annex تنها یک بار برای دریافت گذرواژه از شما درخواست شود. برای نحوه راه‌اندازی کشینگ گذرواژه به gitcredentials(7) مراجعه کنید.
این گزینه مشابه url.<base>.pushInsteadOf در گیت عمل می‌کند و نشانی ریموتی را که با مقدار این پیکربندی آغاز می‌شود بازنویسی می‌کند تا به جای آن با <base> آغاز شود.
نشانی بازنویسی‌شده توسط git-annex برای دسترسی به ریموت استفاده می‌شود و همانند remote.<name>.annexUrl عمل می‌کند، از جمله پشتیبانی از نشانی‌های annex+http.
توجه داشته باشید که git-annex از پیکربندی url.<base>.insteadOf گیت نیز پشتیبانی می‌کند. هنگامی که هر دو تنظیم شده باشند، ابتدا نشانی ریموت توسط insteadOf بازنویسی می‌شود و سپس آن نشانی بازنویسی‌شده می‌تواند مجدداً با استفاده از annexInsteadOf بازنویسی شود.
ابزار git-annex شناسه‌های یکتای جهانی (UUID) مخازن ریموت را در اینجا کش می‌کند.
برای برخی ریموت‌های ویژه استفاده می‌شود و به پیکربندی ریموت ویژه متفاوتی اشاره می‌کند که باید مورد استفاده قرار گیرد.
تعداد دفعاتی که می‌توان یک انتقال ناموفق را مجدداً تلاش کرد. (پیش‌فرض 0)
اگر یک انتقال پیش از شکست مقداری پیشرفت رو به جلو داشته باشد، این گزینه اجازه می‌دهد حتی زمانی که annex.retry اجازه نمی‌دهد، دوباره تلاش شود. مقدار آن حداکثر دفعات انجام این کار است. (پیش‌فرض 5)
هنگامی که هم annex.retry و هم این گزینه تنظیم شده باشند، حداکثر تعداد تلاش مجدد مقدار بزرگ‌تر میان این دو است.
تعداد ثانیه‌های تاخیر پیش از نخستین تلاش مجدد برای یک انتقال. هنگام انجام تلاش‌های مجدد چندگانه برای همان انتقال، این تاخیر پس از هر بار تلاش دو برابر می‌شود. (پیش‌فرض 1)
این گزینه می‌تواند برای محدود کردن میزان پهنای باند مصرفی جهت انتقال از یا به یک ریموت به کار رود.
برای نمونه، جهت محدود کردن انتقال‌ها به ۱ مبی‌بایت بر ثانیه: git config annex.bwlimit "1MiB"
این تنظیم با بسیاری از ریموت‌ها، از جمله ریموت‌های گیت، کار خواهد کرد اما نه برای ریموت‌هایی که در آن‌ها فرایند انتقال توسط برنامه‌ای جداگانه از git-annex اجرا می‌شود.
محدود کردن پهنای باند برای دانلودها از یک ریموت.
تنظیمات remote.<name>.annex-bwlimit و annex.bwlimit را لغو می‌کند.
محدود کردن پهنای باند برای آپلودها به یک ریموت.
تنظیمات remote.<name>.annex-bwlimit و annex.bwlimit را لغو می‌کند.
پیکربندی این گزینه اجازه می‌دهد انتقال‌های متوقف‌شده یا بیش از حد کُند شناسایی شده و به آن‌ها رسیدگی شود، به‌طوری که git-annex به جای گیر کردن، عملیات متوقف‌شده را لغو کند. این انتقال به عنوان ناموفق تلقی خواهد شد، بنابراین تنظیماتی مانند annex.retry رفتار بعدی آن را کنترل می‌کنند.
حالت پیش‌فرض این است که انتقال‌هایی را که احتمالاً متوقف شده‌اند به‌طور خودکار شناسایی کرده و پیکربندی این گزینه را پیشنهاد دهد، اما عملیات متوقف‌شده را لغو نکند. برای کارکرد این قابلیت، ریموت باید وضعیت پیشرفت خود را به‌طور پیوسته به‌روزرسانی کند. ریموت‌هایی که این کار را نمی‌کنند، مشمول تشخیص خودکار توقف نخواهند شد. همچنین در استفاده از تشخیص خودکار توقف، ممکن است مدتی طول بکشد تا git-annex تصمیم بگیرد که یک ریموت واقعاً متوقف شده است، چرا که باید در تشخیص توقف جانب احتیاط را رعایت کند.
جهت پرهیز از هرگونه تلاش برای تشخیص توقف، مقدار آن را روی "false" تنظیم کنید.
برای تشخیص و لغو انتقال‌های متوقف‌شده، این گزینه را روی مقداری به شکل "$amount/$timeperiod" تنظیم کنید که حداقل مقدار داده‌ای را که git-annex در یک بازه زمانی معین انتظار جریان آن را دارد مشخص می‌سازد.
برای نمونه، جهت تشخیص توقف‌های کامل که پس از ۳۰ ثانیه هیچ داده‌ای منتقل نشده است: git config annex.stalldetection "1KB/30s"
یا اگر ریموتی روی یک حافظه USB دارید که معمولاً قادر به انتقال چندین مگابایت بر ثانیه است، اما بدسکتورهایی دارد که در آن‌ها برای مدت طولانی گیر می‌کند، می‌توانید از دستور زیر استفاده کنید: git config remote.usbdrive.annex-stalldetection "1MB/1m"
برخی ریموت‌ها پیشرفت انتقال را گزارش نمی‌کنند و هنگام استفاده از آن‌ها امکان تشخیص توقف وجود ندارد.
برخی ریموت‌ها گزارش پیشرفت را تنها گهگاه ارائه می‌دهند، برای نمونه پس از هر قطعه (chunk). برای پرهیز از هشدارهای کاذب وقفه زمانی (timeout) در چنین شرایطی، اگر دریافت اولین به‌روزرسانی پیشرفت بیشتر از بازه زمانی پیکربندی‌شده طول بکشد، تشخیص توقف به‌طور خودکار تنظیم می‌شود تا از بازه زمانی طولانی‌تری استفاده کند. برای نمونه، اگر اولین گزارش پیشرفت پس از ۱۰ دقیقه برسد، اما مقدار annex.stalldetection برابر با "1MB/1m" باشد، به عنوان نمونه به صورت "30MB/30m" در نظر گرفته خواهد شد.
پیکربندی تشخیص توقف می‌تواند موجب استفاده بیشتر git-annex از منابع شود. برای امکان‌پذیر ساختن لغو توقف‌ها، git-annex باید انتقال‌ها را در فرایندهای جداگانه‌ای اجرا کند (یک فرایند به ازای هر وظیفه هم‌زمان). بنابراین ممکن است نیاز به باز کردن اتصالات بیشتری نسبت به معمول به ریموت داشته باشد، یا ارتباط با آن فرایندها سرعت آن را کمی کاهش دهد.
تشخیص توقف برای دریافت‌ها (دانلودها) از یک ریموت.
برای نمونه، اگر ریموتی اغلب سریع است، اما گاهی بسیار کُند می‌شود، و ریموت دیگری وجود دارد که به‌طور پیوسته سرعت متوسطی دارد و حاوی همان داده‌ها است، می‌توان این گزینه را طوری تنظیم کرد که در هنگام کُند شدن ریموت سریع، آن را متوقف‌شده در نظر بگیرد. سپس دستوری مانند git-annex get برای دانلود به ریموت با سرعت متوسط رجوع خواهد کرد.
تنظیمات remote.<name>.annex-stalldetection و annex.stalldetection را لغو می‌کند.
تشخیص توقف برای بارگذاری‌ها (آپلودها) به یک ریموت.
تنظیمات remote.<name>.annex-stalldetection و annex.stalldetection را لغو می‌کند.
این گزینه تنها بر ریموت‌هایی اثر می‌گذارد که نشانی آن‌ها به یک پوشه روی همان سیستم اشاره دارد. ابزار git-annex معمولاً در هر بار اجرا شناسه یکتای (uuid) چنین ریموت‌هایی را بررسی می‌کند، که به آن امکان می‌دهد با درایوهای گوناگونی که در زمان‌های مختلف در آن مکان متصل (mount) می‌شوند، به‌طور شفاف کار کند.
تنظیم annex-checkuuid روی false مانع از بررسی uuid در هنگام راه‌اندازی می‌شود (اگرچه uuid پیش از اعمال هرگونه تغییر در مخزن ریموت همچنان تایید می‌شود). این گزینه ممکن است برای جلوگیری از چرخش غیرضروری دیسک (spin-up) یا اتصال خودکار یک درایو مفید باشد.
سطح اعتماد محلی را برای ریموت پیکربندی می‌کند. این گزینه مقداری را که با دستورات trust و untrust پیکربندی شده است لغو می‌کند. مقدار آن می‌تواند هر یک از مقادیر "trusted"، "semitrusted" یا "untrusted" باشد.
روی "true" تنظیم کنید تا git-annex فرض کند این ریموت ممکن است حاوی محتوای هر فایلی باشد، حتی با اینکه ردیابی موقعیت مکانی عادی آن نشان ندهد که فایل موجود است. این کار سبب می‌شود git-annex تلاش کند محتوای تمام فایل‌ها را از این ریموت دریافت کند. می‌تواند در راه‌اندازی یک ریموت حافظه موقت (caching) سودمند باشد.
روی "true" تنظیم کنید تا مخزن محلی بتواند به عنوان یک پراکسی برای این ریموت عمل کند. این ریموت می‌تواند یک مخزن git-annex یا یک ریموت ویژه باشد.
پس از پیکربندی این گزینه، دستور git-annex-updateproxy(1) را اجرا کنید تا پیکربندی جدید در شاخه git-annex ذخیره شود.
معمولاً این گزینه به صورت درونی و هنگام راه‌اندازی ریموت‌های پراکسی‌شده توسط git-annex استفاده می‌شود و نیازی به پیکربندی دستی نخواهد داشت. مقدار آن شناسه یکتای جهانی (UUID) مخزن git-annex است که دسترسی به این ریموت را پراکسی می‌کند.
روی نام یک کلاستر تنظیم کنید تا این ریموت بخشی از آن کلاستر شود. نام چندین کلاستر را می‌توان با فاصله از یکدیگر جدا کرد تا یک ریموت بخشی از بیش از یک کلاستر باشد.
پس از پیکربندی این گزینه، دستور git-annex-updatecluster(1) را اجرا کنید تا پیکربندی جدید در شاخه git-annex ذخیره شود.
روی UUID کلاستری تنظیم می‌شود که این ریموت به عنوان یک درگاه (gateway) برای آن عمل می‌کند. می‌توان چندین UUID را که با فاصله از هم جدا شده‌اند فهرست کرد. هنگامی که مخزن محلی نیز یک درگاه برای آن کلاستر باشد، به عنوان پراکسی برای گره‌های درگاه ریموت عمل خواهد کرد.
معمولاً این مورد با اجرای git-annex-extendcluster راه‌اندازی می‌شود.
هنگامی که این گزینه روی true تنظیم شود، هیچ اطلاعاتی در مورد این ریموت در شاخه git-annex ثبت نخواهد شد. این قابلیت عمدتاً برای ریموت‌های ویژه کاربرد دارد و هنگام استفاده از git-annex-initremote(1) به همراه گزینه --private تنظیم می‌شود.
هنگام استفاده از git-remote-annex برای ذخیره یک مخزن گیت در یک ریموت ویژه، این گزینه مشخص می‌کند که پیش از آپلود مجدد یک بسته (bundle) واحد گیت حاوی کل مخزن گیت، چه تعداد شیء باندل گیت جداگانه در ریموت ویژه ذخیره شود.
مقدار پیش‌فرض 100 است که هدف از آن پرهیز از نیاز به آپلود مجدد مکرر است، در حالی که مانع از نیاز کلون یا واکشی (fetch) به دانلود اشیاء بیش از حد زیاد می‌شود. برای غیرفعال کردن آپلود مجدد، آن را روی 0 تنظیم کنید.
تنظیم این گزینه روی true امکان استفاده از git-remote-annex را برای ارسال (push) مخزن گیت به یک ریموت ویژه رمزگذاری‌شده فراهم می‌سازد.
این کار به‌طور پیش‌فرض مجاز نیست، زیرا دستور git clone از یک ریموت ویژه رمزگذاری‌شده غیرممکن است، چرا که به کلیدهای رمزگذاری ذخیره‌شده در ریموت نیاز دارد. بنابراین دقت کنید در صورت فعال‌سازی این تنظیم، به اینکه ریموت ویژه رمزگذاری‌شده تنها نسخه از مخزن گیت شما باشد اتکا نکنید.
می‌تواند برای اعلام به git-annex درباره اینکه آیا یک ریموت یک مخزن bare است یا خیر به کار رود. به‌طور معمول، git-annex این موضوع را به‌صورت خودکار تشخیص می‌دهد.
این تنظیم پیکربندی دیگر استفاده نمی‌شود.
گزینه‌هایی که هنگام استفاده از ssh برای برقراری ارتباط با این ریموت به کار می‌روند.
گزینه‌های مورد استفاده هنگام استفاده از rsync به یا از این ریموت. برای نمونه، جهت اجبار به استفاده از IPv6 و محدود کردن پهنای باند به 100 کیلوبایت بر ثانیه، آن را روی -6 --bwlimit 100 تنظیم کنید.
توجه داشته باشید که git-annex-shell فهرست مجازی از گزینه‌های مجاز rsync دارد و سایر گزینه‌ها به rsync ریموت ارسال نخواهند شد. بنابراین استفاده از برخی گزینه‌ها ممکن است ارتباط میان rsyncهای محلی و ریموت را مختل کند.
گزینه‌هایی که هنگام استفاده از rsync برای بارگذاری (آپلود) یک فایل به یک ریموت به کار می‌روند.
این گزینه‌ها پس از سایر گزینه‌های کاربردی rsync اعمال می‌شوند، بنابراین می‌توانند برای لغو آن‌ها استفاده شوند. برای نمونه، جهت محدود کردن پهنای باند آپلود به 10 کیلوبایت بر ثانیه، گزینه --bwlimit 10 را تنظیم کنید.
گزینه‌هایی که هنگام استفاده از rsync برای دریافت (دانلود) یک فایل از یک ریموت به کار می‌روند.
این گزینه‌ها پس از سایر گزینه‌های کاربردی rsync اعمال می‌شوند، بنابراین می‌توانند برای لغو آن‌ها به کار روند.
پوسته ریموتی که برای اتصال به ریموت rsync استفاده می‌شود. مقادیر ممکن عبارتند از ssh (پیش‌فرض) و rsh، به همراه آرگومان‌های آن‌ها؛ برای نمونه ssh -p 2222 -c blowfish؛ توجه داشته باشید که نام میزبان ریموت نباید در آنجا درج شود، برای جزئیات به rsync(1) مراجعه کنید. هنگامی که حامل مورد استفاده ssh باشد، اتصالات به‌طور خودکار کش می‌شوند مگر اینکه annex.sshcaching لغو شده باشد.
گزینه‌هایی که هنگام ذخیره محتوا در این ریموت به bup split ارسال می‌شوند. برای نمونه، جهت محدود کردن پهنای باند به 100 کیلوبایت بر ثانیه، آن را روی --bwlimit 100k تنظیم کنید. (هیچ گزینه متناظری برای bup join وجود ندارد.)
گزینه‌هایی که هنگام رمزگذاری داده‌ها به GnuPG ارسال می‌شوند. برای نمونه، جهت استفاده از رمزنگاری AES با یک کلید ۲۵۶ بیتی و غیرفعال کردن فشرده‌سازی، آن را روی --cipher-algo AES256 --compress-algo none تنظیم کنید. (این گزینه‌ها بر پیکربندی پیش‌فرض GnuPG که در غیر این صورت استفاده می‌شود، اولویت دارند.)
گزینه‌هایی که هنگام رمزگشایی داده‌ها به GnuPG ارسال می‌شوند. (این گزینه‌ها بر پیکربندی پیش‌فرض GnuPG که در غیر این صورت استفاده می‌شود، اولویت دارند.)
از این دستور، که پیاده‌سازی رابط خط فرمان Stateless OpenPGP است، به جای GnuPG برای رمزگذاری و رمزگشایی داده‌ها استفاده می‌کند. این گزینه تنها زمانی به کار می‌رود که یک ریموت ویژه با encryption=shared پیکربندی شده باشد.
برای نمونه، جهت استفاده از دستور sqop متعلق به Sequoia PGP، این گزینه را روی "sqop" تنظیم کنید.
هنگام رمزگذاری با یک دستور Stateless OpenPGP، این گزینه می‌تواند برای تعیین پروفایل مورد استفاده، مانند "rfc4880"، به کار رود.
برای فهرستی از پروفایل‌های در دسترس، دستوری مانند "sqop list-profiles encrypt" را اجرا کنید:
sqop list-profiles encrypt
توسط ریموت‌های ویژه rsync استفاده می‌شود و مکان مخزن rsync را جهت استفاده پیکربندی می‌کند. معمولاً این مورد به‌طور خودکار توسط git annex initremote تنظیم می‌شود، اما در صورت نیاز می‌توانید آن را تغییر دهید.
توسط ریموت‌های ویژه bup استفاده می‌شود و مکان مخزن bup را جهت استفاده پیکربندی می‌کند. معمولاً این مورد به‌طور خودکار توسط git annex initremote تنظیم می‌شود، اما در صورت نیاز می‌توانید آن را تغییر دهید.
توسط ریموت‌های ویژه borg استفاده می‌شود و مکان مخزن borg را جهت استفاده پیکربندی می‌کند. معمولاً این مورد به‌طور خودکار توسط git annex initremote تنظیم می‌شود، اما در صورت نیاز می‌توانید آن را تغییر دهید.
برای شناسایی ریموت‌های ویژه محاسباتی (compute) استفاده می‌شود. معمولاً این مورد به‌طور خودکار توسط git annex initremote تنظیم می‌شود.
توسط ریموت‌های ویژه ddar استفاده می‌شود و مکان مخزن ddar را جهت استفاده پیکربندی می‌کند. معمولاً این مورد به‌طور خودکار توسط git annex initremote تنظیم می‌شود، اما در صورت نیاز می‌توانید آن را تغییر دهید.
توسط ریموت‌های ویژه پوشه (directory) استفاده می‌شود و مکان پوشه‌ای را که فایل‌های ضمیمه‌شده (annexed) برای این ریموت در آن ذخیره می‌شوند پیکربندی می‌کند. معمولاً این مورد به‌طور خودکار توسط git annex initremote تنظیم می‌شود، اما در صورت نیاز می‌توانید آن را تغییر دهید.
برای شناسایی ریموت‌های موجود روی دستگاه‌های اندرویدی که از طریق adb به آن‌ها دسترسی پیدا می‌شود به کار می‌رود. معمولاً این مورد به‌طور خودکار توسط git annex initremote تنظیم می‌شود.
توسط ریموت‌های ویژه adb استفاده می‌شود؛ این پوشه‌ای در دستگاه اندرویدی است که فایل‌های مربوط به این ریموت در آن ذخیره می‌شوند. معمولاً این مورد به‌طور خودکار توسط git annex initremote تنظیم می‌شود، اما در صورت نیاز می‌توانید آن را تغییر دهید.
توسط ریموت‌های ویژه adb استفاده می‌شود؛ این شماره سریال دستگاه اندرویدی است که توسط ریموت استفاده می‌شود. معمولاً این مورد به‌طور خودکار توسط git annex initremote تنظیم می‌شود، اما در صورت نیاز می‌توانید آن را تغییر دهید، برای نمونه هنگام ارتقا به یک دستگاه اندرویدی جدید.
برای شناسایی ریموت‌های ویژه Amazon S3 استفاده می‌شود. معمولاً این مورد به‌طور خودکار توسط git annex initremote تنظیم می‌شود.
هنگام استفاده از ریموت ویژه Amazon S3، این گزینه رده (tier) مورد استفاده هنگام بازیابی اشیاء از فضای ذخیره‌سازی عمیق (deep storage) را مشخص می‌کند. می‌تواند روی "standard" (پیش‌فرض)، "bulk" یا "expedited" تنظیم شود.
هنگام استفاده از ریموت ویژه Amazon S3، این گزینه مشخص می‌کند اشیائی که از فضای ذخیره‌سازی عمیق بازیابی شده‌اند تا چند روز باید در دسترس باقی بمانند. مقدار پیش‌فرض ۱ روز است.
برای شناسایی ریموت‌های ویژه Amazon Glacier استفاده می‌شود. معمولاً این مورد به‌طور خودکار توسط git annex initremote تنظیم می‌شود.
برای شناسایی ریموت‌های ویژه rclone استفاده می‌شود. معمولاً این مورد به‌طور خودکار توسط git annex initremote تنظیم می‌شود.
برای شناسایی ریموت‌های ویژه وب استفاده می‌شود. معمولاً این مورد به‌طور خودکار توسط git annex initremote تنظیم می‌شود.
برای شناسایی ریموت‌های ویژه webdav استفاده می‌شود. معمولاً این مورد به‌طور خودکار توسط git annex initremote تنظیم می‌شود.
برای شناسایی ریموت‌های ویژه tahoe استفاده می‌شود. به پوشه پیکربندی برای tahoe اشاره می‌کند.
برای شناسایی ریموت‌های ویژه gcrypt استفاده می‌شود. معمولاً این مورد به‌طور خودکار توسط git annex initremote تنظیم می‌شود.
اگر این ریموت یک ریموت gcrypt باشد، روی "true" تنظیم می‌شود. اگر ریموت gcrypt از طریق ssh در دسترس باشد و git-annex-shell برای مدیریت آن موجود باشد، روی "shell" تنظیم می‌شود.
برای شناسایی ریموت‌های ویژه git-lfs استفاده می‌شود. معمولاً این مورد به‌طور خودکار توسط git annex initremote تنظیم می‌شود.
اگر این یک ریموت git-lfs باشد، روی "true" تنظیم می‌شود.
برای شناسایی ریموت‌های ویژه httpalso استفاده می‌شود. معمولاً این مورد به‌طور خودکار توسط git annex initremote تنظیم می‌شود.
توسط ریموت‌های ویژه mask استفاده می‌شود؛ این گزینه روی نام ریموتی که ماسک شده است تنظیم می‌شود. اگر این مقدار روی "true" تنظیم شود، هر ریموتی با UUID مناسب استفاده خواهد شد. معمولاً این مورد به‌طور خودکار توسط git annex initremote تنظیم می‌شود.
توسط ریموت‌های ویژه خارجی برای ثبت نوع ریموت استفاده می‌شود.
برای نمونه، اگر این گزینه روی "foo" تنظیم شود، git-annex یک برنامه "git-annex-remote-foo" را برای برقراری ارتباط با ریموت ویژه خارجی اجرا می‌کند.
اگر این گزینه روی "readonly" تنظیم شود، در این صورت git-annex هیچ برنامه ریموت ویژه خارجی را اجرا نخواهد کرد، بلکه تلاش می‌کند با استفاده از http به موارد ذخیره‌شده در ریموت دسترسی یابد. این روش تنها برای برخی ریموت‌های ویژه خارجی عمل می‌کند، بنابراین به مستندات ریموتی که استفاده می‌کنید مراجعه فرمایید.
توسط ریموت‌های ویژه هوک برای ثبت نوع ریموت استفاده می‌شود.
گزینه‌هایی که هنگام استفاده از curl توسط git-annex برای دانلود نشانی‌های وب به آن ارسال می‌شوند (به جای دانلودکننده درون‌ساخت پیش‌فرض urlها).
برای نمونه، جهت اجبار به استفاده از فقط IPv4، آن را روی "-4" تنظیم کنید.
تنظیم این گزینه باعث می‌شود git-annex از curl استفاده کند، اما تنها در صورتی که annex.security.allowed-ip-addresses به شیوه‌ای خاص پیکربندی شده باشد. مستندات آن را ببینید.
تنظیم این گزینه مانع از استفاده git-annex از git-credential برای درخواست گذرواژه‌های http می‌شود. در عوض، می‌توانید "--netrc" را بگنجانید تا curl از فایل ~/.netrc شما استفاده کرده و گذرواژه‌ها را در آنجا ثبت کند.
گزینه‌هایی که به yt-dlp ارسال می‌شوند. برای نمونه اگر یوتیوب برای دانلود به کوکی نیاز دارد، از عبارتی مانند "--cookies-from-browser firefox"; استفاده کنید.
برخی گزینه‌ها ممکن است سازگاری و یکپارچگی git-annex با yt-dlp را مختل کنند. برای نمونه، گزینه --output می‌تواند سبب شود که فایل‌ها در جایی ذخیره شوند که git-annex نتواند آن‌ها را پیدا کند. از تنظیم هرگونه گزینه‌ای در اینجا یا در فایل پیکربندی yt-dlp که موجب دانلود بیش از یک فایل شود، یا فایل را در جایی غیر از پوشه کاری جاری ذخیره کند، خودداری کنید.
منسوخ‌شده و بدون استفاده. git-annex همواره "yt-dlp" را اجرا می‌کند، چرا که دستور "youtube-dl" منسوخ شده است.
گزینه‌های ارسالی به aria2c هنگام استفاده از آن برای دانلود یک تورنت.
هدرهای HTTP که هنگام دانلود از وب ارسال می‌شوند. چندین خط از این گزینه می‌تواند تنظیم شود، یک خط به ازای هر هدر.
در صورت تنظیم، این دستور اجرا می‌شود و هر خط از خروجی آن به عنوان یک هدر HTTP استفاده خواهد شد. این گزینه annex.http-headers را لغو می‌کند.
روش دیگر این است که یک اسکریپت هوک در .git/hooks/http-headers-annex نصب شود.
فهرستی از طرح‌های URL که git-annex مجاز است محتوا را از آن‌ها دانلود کند. مقدار پیش‌فرض "http https ftp" است.
پیش از تغییر این گزینه بسیار با دقت بیندیشید؛ این امر پیامدهای امنیتی به همراه دارد. برای نمونه، اگر طوری تغییر یابد که نشانی‌های URL از نوع "file" را مجاز کند، در این صورت هر فردی که بتواند یک کامیت وارد مخزن git-annex شما کند می‌تواند با git-annex addurl به یک فایل خصوصی در خارج از آن مخزن اشاره کند و احتمالاً باعث شود آن فایل در مخزن شما کپی شده و به سایر ریموت‌ها منتقل گردد و محتوای آن افشا شود.
هر طرح URL که توسط curl پشتیبانی می‌شود می‌تواند در اینجا فهرست شود، اما همچنین لازم است annex.security.allowed-ip-addresses را نیز برای مجاز ساختن استفاده از curl پیکربندی کنید.
برخی ریموت‌های ویژه از طرح‌های URL مختص به دامنه خود پشتیبانی می‌کنند؛ آن موارد تحت تاثیر این تنظیم پیکربندی قرار نمی‌گیرند.
به‌طور پیش‌فرض، git-annex تنها به آدرس‌های IP عمومی متصل می‌شود؛ این ابزار از استفاده از سرورهای HTTP و سایر سرورها روی localhost یا روی یک شبکه خصوصی امتناع خواهد کرد.
این تنظیم می‌تواند آن رفتار را لغو کرده و اجازه دسترسی به آدرس‌های IP خاصی را که در حالت عادی مسدود می‌شوند صادر کند. برای نمونه "127.0.0.1 ::1" دسترسی به localhost (هم IPV4 و هم IPV6) را مجاز می‌کند. برای دسترسی به همه آدرس‌های IP، از "all" استفاده کنید.
پیش از تغییر این گزینه بسیار با دقت بیندیشید؛ این امر پیامدهای امنیتی به همراه دارد. هر کسی که بتواند کامیتی را وارد مخزن git-annex شما کند، می‌تواند با git annex addurl یک نشانی را روی یک سرور خصوصی اضافه کند و احتمالاً سبب شود که آن فایل در مخزن شما دانلود شده و به سایر ریموت‌ها ارسال گردد و محتوای آن فاش شود.
توجه داشته باشید از آنجا که واسط‌های curl و yt-dlp اجازه اعمال این محدودیت‌های آدرس IP را نمی‌دهند، curl و yt-dlp هرگز استفاده نخواهند شد مگر آنکه annex.security.allowed-ip-addresses=all تنظیم شده باشد.
برای مجاز ساختن دسترسی به آدرس‌های IP محلی یا خصوصی تنها روی درگاه‌های (پورت‌های) خاص، از ساختار "[addr]:port" استفاده کنید. برای نمونه، "[127.0.0.1]:80 [127.0.0.1]:443 [::1]:80 [::1]:443" دسترسی به localhost را تنها روی درگاه‌های http مجاز می‌کند.
نام قدیمی برای annex.security.allowed-ip-addresses. در صورت تنظیم، مشابه با تنظیم بودن annex.security.allowed-ip-addresses در نظر گرفته می‌شود.
به دلایل امنیتی، git-annex از دانلود محتوا از اغلب ریموت‌های ویژه در صورتی که نتواند هش را برای بررسی صحت محتوای دانلودشده تایید کند، امتناع می‌ورزد. این امر به ویژه بر دانلود محتوای کلیدهای URL یا WORM که فاقد هش هستند اثر می‌گذارد.
بهترین شیوه برای پرهیز از مشکلات ناشی از این مسئله، انتقال فایل‌ها از چنین کلیدهایی پیش از رسیدن محتوای آن‌ها به یک ریموت ویژه است. به git-annex-migrate(1) مراجعه کنید.
هنگامی که محتوا تنها از یک ریموت ویژه در دسترس باشد، می‌توانید از این پیکربندی استفاده کنید تا git-annex را ملزم به دانلود آن نمایید. اما شما این کار را با مسئولیت خودتان انجام می‌دهید و بسیار مهم است که ابتدا اطلاعات زیر را بخوانید و درک کنید!
از دانلود محتوای تاییدنشده از ریموت‌های ویژه رمزگذاری‌شده جلوگیری می‌شود، زیرا ریموت ویژه می‌تواند محتوای رمزگذاری‌شده دیگری غیر از آنچه انتظار دارید ارسال کند، که موجب می‌شود git-annex داده‌هایی را که هرگز وارد git-annex نکرده‌اید رمزگشایی کند و خطر افشای داده‌های رمزگشایی‌شده به هر ریموت رمزگذاری‌نشده‌ای که محتوا به آن ارسال می‌کنید وجود داشته باشد.
از دانلود محتوای تاییدنشده از ریموت‌های ویژه خارجی (غیر رمزگذاری‌شده) جلوگیری می‌شود، چرا که آن‌ها می‌توانند ریدایرکت‌های http را به وب‌سرورهای روی localhost یا روی شبکه خصوصی، یا در برخی موارد به یک url از نوع file:/// دنبال کنند.
اگر تصمیم به دور زدن این بررسی امنیتی گرفتید، بهترین کار این است که آن را تنها به‌طور موقت در حین اجرای دستوری که فایل را دریافت می‌کند تنظیم کنید. مقداری که باید برای این پیکربندی تنظیم شود "ACKTHPPT" است. برای نمونه:

git -c annex.security.allow-unverified-downloads=ACKTHPPT annex get myfile
همچنین ایده خوبی است که بررسی کنید آیا فایلی را که انتظار داشتید دانلود کرده است یا خیر.
پیکربندی به ازای هر ریموت برای annex.security.allow-unverified-downloads.
این یک فهرست جداشده با فاصله از برنامه‌های محاسباتی است، برای نمونه "git-annex-compute-foo git-annex-compute-bar". درج نام یک برنامه محاسباتی در اینجا به ریموت‌های ویژه محاسباتی که از آن برنامه استفاده می‌کنند اجازه می‌دهد توسط git-annex enableremote یا به‌طور خودکار فعال شوند.

دستورات watch و assistant را وادار می‌کند تا پیش از افزودن یک فایل تازه ایجادشده به annex، به مدت تعداد ثانیه‌های مشخص‌شده درنگ کنند. به‌طور معمول به این گزینه نیازی نیست، زیرا آن‌ها از پیش منتظر می‌مانند تا تمام نویسندگان فایل آن را ببندند.
توجه داشته باشید که این گزینه فقط افزودن فایل‌های ایجادشده در زمان اجرای دیمون را به تاخیر می‌اندازد. تغییرات انجام‌شده در زمانی که دیمون در حال اجرا نیست، بلافاصله در راه‌اندازی بعدی افزوده خواهند شد.
اقدام دستیار (assistant) را در مورد محتویات استفاده‌نشده فایل‌ها که در مخزن ذخیره شده‌اند کنترل می‌کند.
مقدار پیش‌فرض false است که سبب می‌شود تمام محتویات قدیمی و استفاده‌نشده فایل‌ها حفظ شوند، مگر آنکه دستیار بتواند آن‌ها را به مخزن دیگری (مانند مخزن پشتیبان) منتقل کند.
می‌تواند روی یک مشخصه زمانی مانند "7d" یا "1m" تنظیم شود و در نتیجه محتویات فایلی که مشخص شده است برای یک هفته یا یک ماه استفاده نشده‌اند، حذف خواهند شد.
هنگامی که روی false تنظیم شود، از یادآوری برنامه تحت وب هنگام استفاده از مخازنی که فاقد بررسی‌های یکپارچگی هستند جلوگیری می‌کند.
هنگامی که روی ask تنظیم شود (پیش‌فرض)، برنامه تحت وب نگارش‌های جدید را بررسی کرده و در صورت وجود از شما می‌پرسد که آیا باید به آن‌ها ارتقا یابد یا خیر. هنگامی که روی true تنظیم شود، بدون پرسش به‌طور خودکار ارتقا می‌یابد (در برخی پلتفرم‌های پشتیبانی‌شده). هنگامی که روی false تنظیم شود، هرگونه بررسی ارتقا را غیرفعال می‌کند.
توجه داشته باشید که بررسی ارتقا تنها زمانی صورت می‌پذیرد که git-annex از یکی از ایمیج‌های از پیش ساخته وب‌سایت آن نصب شده باشد. این تنظیم کدهای رسیدگی به ارتقای اختصاصی، به عنوان نمونه متعلق به یک توزیع لینوکس را دور نمی‌زند.
این تنظیم همچنین کنترل می‌کند که آیا در صورت تشخیص تغییر فایل اجرایی git-annex، دستیار git-annex مجدداً راه‌اندازی شود یا خیر. این مورد فارغ از شیوه نصب git-annex مفید است.
روی false تنظیم کنید تا از ثبت (commit) خودکار تغییرات فایل‌ها در مخزن توسط git-annex assistant، git-annex assist و git-annex sync جلوگیری به عمل آید.
جهت پیکربندی این رفتار در تمامی رونوشت‌های (clones) مخزن، این گزینه می‌تواند در git-annex-config(1) تنظیم شود.
روی false تنظیم کنید تا از پویش مخزن برای فایل‌های جدید و تغییریافته در هنگام راه‌اندازی توسط دستیار git-annex جلوگیری شود. این کار مانع از آگاهی آن از تغییراتی می‌شود که در زمان عدم اجرای آن ایجاد شده‌اند، اما می‌تواند یک بهینه‌سازی کارایی کارآمد برای مخازن بزرگ باشد.
آدرس IP که برنامه تحت وب روی آن گوش می‌دهد را پیکربندی می‌کند. مقدار پیش‌فرض localhost است. می‌تواند یک آدرس IP یا یک نام میزبان باشد که به آدرس مورد نظر اشاره دارد.
شماره درگاهی (پورتی) که برنامه تحت وب روی آن گوش می‌دهد را پیکربندی می‌کند. مقدار پیش‌فرض انتخاب یک درگاه استفاده‌نشده است.

بک‌اند کلید-مقدار (key-value) مورد استفاده هنگام افزودن فایلی جدید به annex را می‌توان بر پایه هر نوع فایل از طریق فایل‌های .gitattributes پیکربندی کرد. در این فایل، ویژگی annex.backend می‌تواند روی نام بک‌اند مورد استفاده تنظیم شود. (برای اطلاعات درباره بک‌اندهای موجود به git-annex-backends(1) مراجعه کنید.) برای نمونه، در اینجا نحوه استفاده از بک‌اند WORM به‌طور پیش‌فرض، و استفاده از بک‌اند SHA256E برای فایل‌های ogg آورده شده است:


* annex.backend=WORM
*.ogg annex.backend=SHA256E

ویژگی annex.largefiles وجود دارد که برای پیکربندی اینکه چه فایل‌هایی به اندازه کافی بزرگ هستند تا به annex اضافه شوند استفاده می‌شود. از آنجا که ویژگی‌ها نمی‌توانند حاوی فاصله باشند، استفاده از آن برای تنظیمات پیچیده‌تر annex.largefiles دشوار است. تنظیم annex.largefiles در git-annex-config(1) روش آسان‌تری جهت پیکربندی آن در تمامی کلون‌های مخزن است. برای جزئیات در مورد نحو، git-annex-matching-expression(1) را ببینید.

تنظیمات numcopies و mincopies را نیز می‌توان بر مبنای هر نوع فایل از طریق ویژگی‌های annex.numcopies و annex.mincopies در فایل‌های .gitattributes پیکربندی کرد. این ویژگی‌ها بر سایر تنظیمات اولویت دارند. برای نمونه، این کار سبب می‌شود ۲ رونوشت برای فایل‌های wav و ۳ رونوشت برای فایل‌های flac مورد نیاز باشد:


*.wav annex.numcopies=2
*.flac annex.numcopies=3

این تنظیمات توسط git-annex در هر زمان که روی یک فایل منطبق عمل می‌کند رعایت می‌شوند. با این حال، هنگام استفاده از --all، --unused یا --key برای مشخص کردن کلیدهایی که باید پردازش شوند، git-annex روی کلیدها عمل می‌کند و نه روی فایل‌ها، بنابراین تنظیمات حاصل از .gitattributes را اعمال نخواهد کرد. به همین دلیل، دستورات git annex numcopies و git annex mincopies برای پیکربندی یک پیش‌فرض سراسری مفید هستند.

همچنین توجه داشته باشید هنگام استفاده از نماها (views)، تنها فایل .gitattributes سطح بالا در نما حفظ می‌شود، بنابراین تنظیمات دیگر در فایل‌های دیگر اثری نخواهند داشت.

خودِ git-annex در صورت موفقیت با 0 و در صورت شکست با 1 خارج خواهد شد، مگر آنکه به گزینه --size-limit یا --time-limit برخورد کند که در این حالت با 101 خارج می‌شود.

تعداد کمی از زیردستورات git-annex وضعیت‌های خروج دیگری دارند که برای نشان دادن مشکلات خاص استفاده می‌شوند و در صفحات راهنمای اختصاصی خود مستند شده‌اند.

این متغیرهای محیطی در صورت تنظیم شدن، توسط git-annex استفاده می‌شوند:

همانند رفتار گیت با آن‌ها مدیریت می‌شوند، git(1) را ببینید.
مشابه آنچه در git(1) توصیف شده است مدیریت می‌شوند. تنها تفاوت این است که git-annex گاهی یک پارامتر اضافی "-n" را به عنوان اولین پارامتر به این‌ها ارسال می‌کند تا مانع خواندن ssh از ورودی استاندارد (stdin) شود. از آنجا که این کار می‌تواند کاربردهای موجود از این متغیرهای محیطی را که انتظار این پارامتر اضافی را ندارند دچار مشکل کند، لازم است GIT_ANNEX_USE_GIT_SSH=1 را تنظیم کنید تا git-annex از این‌ها پشتیبانی کند.
توجه داشته باشید که تنظیم هر یک از این متغیرهای محیطی مانع از فعال‌سازی خودکار کشینگ اتصال ssh توسط git-annex می‌شود (به annex.sshcaching مراجعه کنید)، بنابراین برخی از عملیات با ریموت‌ها از طریق ssh را کُند خواهد کرد. فعال‌سازی کشینگ اتصال ssh در صورت نیاز بر عهده شماست؛ مستندات ssh را ببینید.
همچنین، در هنگام تنظیم این متغیرهای محیطی، annex.ssh-options و remote.<name>.annex-ssh-options هیچ اثری نخواهند داشت.
معمولاً بهتر است هرگونه گزینه دلخواه را از طریق فایل ~/.ssh/config خود، یا با تنظیم annex.ssh-options پیکربندی کنید.
به‌طور معمول git-annex روی خطوط فایل‌های گزارش متعهدشده (کامیت‌شده) در شاخه git-annex برچسب زمانی درج می‌کند. تنظیم این متغیر محیطی روی یک عدد سبب می‌شود git-annex به جای تعداد ثانیه‌های جاری از مبدا یونیکس (UNIX epoch)، از آن عدد (یا عددی بزرگ‌تر) استفاده کند. توجه داشته باشید که ثانیه‌های اعشاری نیز پشتیبانی می‌شوند.
این گزینه تنها برای کاربران پیشرفته‌ای ارائه شده است که یا روش بهتری نسبت به ساعت محلی برای تشخیص اینکه کدام کامیت جاری است دارند، یا بنا به دلایل خط‌مشی و سیاست‌ها نیاز دارند از گنجاندن برچسب‌های زمانی خودداری کنند.
برخی ریموت‌های ویژه از متغیرهای محیطی دیگری استفاده می‌کنند
برای احراز هویت و غیره. برای نمونه، AWS_ACCESS_KEY_ID و GIT_ANNEX_P2P_AUTHTOKEN. مستندات ریموت ویژه را ببینید.

این فایل‌ها توسط git-annex استفاده می‌شوند:

پوشه .git/annex/objects/ در مخزن گیت شما حاوی محتویات فایل‌های ضمیمه‌شده‌ای است که در حال حاضر در دسترس هستند. فایل‌های ضمیمه‌شده در مخزن گیت شما به آن محتوا پیوند نمادین (symlink) دارند.

پوشه .git/annex/ در مخزن گیت شما حاوی سایر اطلاعات زمان اجرای مورد استفاده توسط git-annex است.

فایل ~/.config/git-annex/autostart فهرستی از مخازن گیت است که باید دستیار git-annex در آن‌ها شروع به کار کند.

مستندات بیشتر درباره git-annex در وب‌سایت آن در دسترس است: https://git-annex.branchable.com

اگر git-annex از طریق یک بسته نصب شده باشد، رونوشتی از مستندات آن باید به عنوان نمونه در /usr/share/doc/git-annex/ گنجانده شده باشد.

Joey Hess <id@joeyh.name>

https://git-annex.branchable.com