jj-fix(1) General Commands Manual jj-fix(1)

jj-fix - به‌روزرسانی فایل‌ها با اصلاحات قالب‌بندی یا سایر تغییرات

jj fix [-R|--repository] [-s|--source] [--ignore-working-copy] [--include-unchanged-files] [-a|--all-lines] [--no-integrate-operation] [--ignore-immutable] [--at-operation] [--debug] [--color] [--quiet] [--no-pager] [--config] [--config-file] [-h|--help] [FILESETS]

به‌روزرسانی فایل‌ها با اصلاحات قالب‌بندی یا سایر تغییرات

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

تغییرات اعمال‌شده توسط jj fix را می‌توان با jj op show -p بررسی کرد.

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

هنگام اصلاح چندین کامیت، اگر محتوای یکسانی از یک فایل در همان مسیر درون کامیت‌های مختلف وجود داشته باشد، ابزار فقط یک بار اجرا می‌شود و از نتیجه مجدداً استفاده می‌گردد. این بدان معناست که ابزارهای مورد استفاده با jj fix باید خروجی قطعی و یکنواخت (deterministic) تولید کنند.

برای درک نحوهٔ پیکربندی ابزارهای خود، فصل Code formatting and other file content transformations را در jj help -k config مشاهده کنید.

پیکربندی زیر را در نظر بگیرید. ما دو ابزار قالب‌بندی کد داریم (clang-format و black) که برای سه پسوند فایل مختلف (.cc, .h و .py) اعمال می‌شوند:

[fix.tools.clang-format]
command = ["/usr/bin/clang-format", "--assume-filename=$path"]
patterns = ["glob:'**/*.cc'",
            "glob:'**/*.h'"]
[fix.tools.black]
command = ["/usr/bin/black", "-", "--stdin-filename=$path"]
patterns = ["glob:'**/*.py'"]

اکنون ببینیم هنگام اجرای jj fix چه اتفاقی برای تاریخچهٔ زیر خواهد افتاد:

C (mutable)
|  Modifies file: foo.py
|
B @ (working copy - mutable)
|  Modifies file: README.md
|
A (mutable)
|  Modifies files: src/bar.cc and src/bar.h
|
X (immutable)

به‌طور پیش‌فرض، دستور jj fix بازنگری‌هایی را تغییر می‌دهد که با مجموعه بازبینی (revset) reachable(@, mutable()) مطابقت داشته باشند (مشاهده کنید: jj help -k revsets) که در اینجا با بازنگری‌های A، B و C همخوانی دارد.

سپس عملیات‌های زیر رخ خواهد داد:

  • برای بازنگری A، محتویات این بازنگری برای فایل‌های src/bar.cc و src/bar.h به clang-format داده خواهد شد، و خروجی حاصل برای ایجاد مجدد بازنگری A استفاده می‌شود، که آن را A' می‌نامیم. تمامی فایل‌های دیگر دست‌نخورده باقی می‌مانند.
  • برای بازنگری B، همین اتفاق برای فایل‌های src/bar.cc و src/bar.h می‌افتد. محتویات آن‌ها از بازنگری B از clang-format عبور خواهد کرد. فایل README.md، همانند سایر فایل‌ها، دست‌نخورده باقی می‌ماند زیرا هیچ الگویی با آن تطابق ندارد. ما بازنگری B' را به دست می‌آوریم.
  • برای بازنگری C، فایل‌های src/bar.cc و src/bar.h از clang-format عبور می‌کنند و فایل foo.py با استفاده از black اصلاح می‌شود. تمامی فایل‌های دیگر دست‌نخورده می‌مانند. ما بازنگری C' را به دست می‌آوریم.
C (mutable)                    /-> C'
|  src/bar.cc -> clang-format -|   |
|  src/bar.h --> clang-format -|   |
|  foo.py -----> black --------|   |
|  * --------------------------/   |
|                                  |
B @ (working copy - mutable)   /-> B' @
|  src/bar.cc -> clang-format -|   |
|  src/bar.h --> clang-format -|   |
|  * --------------------------|   |
|                                  |
A (mutable)                    /-> A'
|  src/bar.cc -> clang-format -|   |
|  src/bar.h --> clang-format -|   |
|  * --------------------------/   |
|                                  |
X (immutable)                      X

اکنون تمام بازنگری‌ها طبق پیکربندی به‌طور صحیح قالب‌بندی شده‌اند.

اصلاح فایل‌ها در بازنگری(های) مشخص‌شده و نوادگان آن‌ها. اگر هیچ بازنگری‌ای مشخص نشود، این گزینه به‌طور پیش‌فرض به تنظیم revsets.fix یا در صورت تنظیم نشدن آن، به reachable(@, mutable()) تغییر می‌یابد
اصلاح فایل‌های تغییرنیافته علاوه بر فایل‌های تغییریافته. اگر هیچ مسیری مشخص نشود، تمام فایل‌های موجود در مخزن اصلاح خواهند شد
قالب‌بندی تمام خطوط به‌جای فقط خطوط تغییریافته.

اگر ابزار قالب‌بندی از قالب‌بندی فقط خطوط تغییریافته پشتیبانی نکند، این گزینه هیچ تأثیری نخواهد داشت چرا که ابزار قالب‌بندی همواره تمام خطوط را قالب‌بندی می‌کند.

چاپ راهنما (مشاهده خلاصه با '-h')
[FILESETS]
فقط این مسیرها اصلاح شوند

مسیر مخزنی که باید روی آن کار شود

به‌طور پیش‌فرض، Jujutsu به دنبال نزدیک‌ترین دایرکتوری .jj/ در مسیرهای والد دایرکتوری کاری فعلی می‌گردد.

از نسخهٔ کاری اسنپ‌شات گرفته نشود و به‌روزرسانی نیز نگردد

به‌طور پیش‌فرض، Jujutsu در ابتدای هر دستور از نسخهٔ کاری اسنپ‌شات می‌گیرد. همچنین در پایان دستور، اگر دستور کامیت نسخهٔ کاری (`@`) را تغییر داده باشد، نسخهٔ کاری به‌روزرسانی می‌شود. اگر می‌خواهید از اسنپ‌شات گرفتن از نسخهٔ کاری صرف‌نظر کنید و در عوض یک کامیت نسخهٔ کاری احتمالاً قدیمی را مشاهده کنید، می‌توانید از --ignore-working-copy استفاده کنید. این مورد می‌تواند برای مثال در خط فرمان (prompt) مفید باشد، به‌ویژه اگر فرآیند دیگری داشته باشید که نسخهٔ کاری را کامیت می‌کند.

بارگذاری مخزن در یک عملیات خاص با --at-operation به معنای فعال بودن --ignore-working-copy است.

اجرای دستور به صورت معمول اما بدون ادغام عملیات‌ها

هنگامی که این گزینه ارائه شود، عملیات‌ها همچنان مثل همیشه ایجاد می‌شوند اما در گزارش عملیات (operation log) ادغام نخواهند شد. همچنین نسخهٔ کاری به‌روزرسانی نخواهد شد.

این دستور شناسهٔ عملیات حاصل را چاپ می‌کند. می‌توانید آن را مثلاً به jj --at-op ارسال کنید تا وضعیت مخزن حاصل را بررسی کنید، یا آن را به jj op restore بدهید تا مخزن را به آن وضعیت بازیابی کند. همچنین می‌توانید شناسه را به jj op integrate بدهید تا عملیات را ادغام نماید.

توجه داشته باشید که این گزینه مانع اثرات جانبی بیرون از مخزن *نمی‌شود*. برای نمونه، دستور jj git push --no-integrate-operation همچنان عملیات پوش (push) را انجام خواهد داد.

اجازه بازنویسی کامیت‌های تغییرناپذیر

به‌طور پیش‌فرض، Jujutsu از بازنویسی کامیت‌های موجود در مجموعهٔ پیکربندی‌شدهٔ کامیت‌های تغییرناپذیر جلوگیری می‌کند. این گزینه بررسی مذکور را غیرفعال کرده و اجازه می‌دهد هر کامیتی به جز کامیت ریشه (root commit) را بازنویسی کنید.

این گزینه فقط بر روی این بررسی تأثیر می‌گذارد و روی مجموعه بازبینی (revset) immutable_heads() یا کلمه کلیدی الگوی immutable اثری ندارد.

عملیاتی که مخزن بر مبنای آن بارگذاری شود

عملیاتی که مخزن باید بر مبنای آن بارگذاری شود. به‌طور پیش‌فرض، Jujutsu مخزن را بر مبنای جدیدترین عملیات یا در صورت وجود، بر مبنای ادغام عملیات‌های واگرا بارگذاری می‌کند.

می‌توانید از --at-op=<operation ID> استفاده کنید تا ببینید مخزن در یک عملیات پیشین به چه شکلی بوده است. برای مثال، دستور jj --at-op=<operation ID> st آنچه را که jj st بلافاصله پس از پایان عملیات مشخص‌شده نشان می‌داد، به شما نمایش می‌دهد. --at-op=@ تقریباً همانند حالت پیش‌فرض است، با این تفاوت که عملیات‌های واگرا هرگز ادغام نخواهند شد.

از دستور jj op log برای یافتن شناسهٔ عملیات دلخواه خود استفاده کنید. هر پیشوند یکتایی از شناسهٔ عملیات کافی است.

هنگام بارگذاری مخزن در یک عملیات قبلی، نسخهٔ کاری نادیده گرفته می‌شود، درست مانند اینکه --ignore-working-copy مشخص شده باشد.

امکان اجرای دستورات تغییردهنده وضعیت (mutating) هنگام بارگذاری مخزن در یک عملیات قبلی وجود دارد. انجام این کار معادل اجرای دستورات همزمان با شروع از عملیات پیشین است. به‌ندرت دلیلی برای انجام این کار وجود دارد، اما امکان‌پذیر است.

فعال‌سازی گزارش‌گیری اشکال‌زدایی (debug logging)
زمان رنگی‌سازی خروجی

مقادیر مجاز:

  • always
  • never
  • debug
  • auto
بی‌صدا کردن خروجی‌های غیر اصلی دستور

برای نمونه، دستور jj file list همچنان فایل‌ها را فهرست می‌کند، اما به شما اطلاع نمی‌دهد که از نسخهٔ کاری اسنپ‌شات گرفته شده است یا نوادگان بازپایه‌ریزی (rebase) شده‌اند.

هشدارها و خطاها همچنان چاپ خواهند شد.

غیرفعال کردن صفحه‌بندی (pager)
گزینه‌های پیکربندی اضافی (قابل تکرار)

نام باید به صورت کلیدهای نقطه‌دار TOML مشخص شود. مقدار باید به عنوان یک عبارت TOML تعیین شود. در صورتی که مقدار رشته‌ای در هیچ‌یک از ساختارهای TOML (مانند نشانه‌گذاری آرایه) محصور نشده باشد، می‌توان علامت نقل‌قول را حذف کرد.

فایل‌های پیکربندی اضافی (قابل تکرار)

jj(1)

fix