"خانه
توسعه گیت
هک کردن گیت
فرآیند بازپرداخت هزینه سفر
اخبار گیت ریویو
درباره اخبار Git Rev
آخرین اخبار Git Rev
بایگانی اخبار Git Rev
منابع خبری Git Rev
مربیگری
اطلاعات عمومی درخواست
اطلاعات عمومی ریزپروژه
مطالب تاریخی SoC و اطلاعرسانی
راهنمای برنامه راهنمایی
مربیگری-SoC
ایدههای SoC 2026
ریزپروژههای متقاضی SoC 2026
شرکتکنندگان در SoC
راهنمایی-اطلاع رسانی
شرکتکنندگان در فعالیتهای ترویجی
مقدمه
ابتدا مطمئن شوید که دستورالعملها و پیشنهادهای کلی ما برای پروژههای خرد را خوانده و درک کردهاید .
در این سند، پیشنهادهایی برای چگونگی یافتن برخی از ریزپروژهها به تنهایی ارائه شده است.
ایدههایی برای پروژههای خرد
مدرنسازی بررسی مسیر تست در مجموعه تست گیت
با تبدیل بررسیهای مسیر قدیمی به توابع کمکی مدرن، به بهبود مجموعه تست گیت کمک کنید. ما دستورات تست پوسته پایه مانند را test -f با کمککنندههای تست اختصاصی گیت مانند test_path_is_file. جایگزین خواهیم کرد.
مراحل تکمیل
با استفاده از بررسیهای مسیر به سبک قدیمی، یک اسکریپت آزمایشی پیدا کنید:
git grep "test -[efd]" t/
به دنبال الگوهایی مانند موارد زیر باشید:
test -f path/to/file # old way
test_path_is_file path/to/file # new way
test -d some/directory # old way
test_path_is_dir some/directory # new way
مهم: فقط بررسیهایی را جایگزین کنید که واقعاً شرایط را آزمایش میکنند، نه آنهایی که در کنترل جریان استفاده میشوند. برای مثال:
DON'T change this - it's flow control
if test -e "file.txt"; then
do_something
fi
DO change this - it's a test assertion
test -e "file.txt" || error "file.txt should exist"
یادداشتها
از کوچک شروع کنید: یک فایل آزمایشی با تعداد کمی نمونه برای تبدیل انتخاب کنید
بعد از تغییرات، مجموعه تست را اجرا کنید تا مطمئن شوید هیچ مشکلی وجود ندارد
از سبک پیام کامیت گیت پیروی کنید
دستوری که برای پیدا کردن نمونهها استفاده کردید را در پیام کامیت خود ذکر کنید
به کمک نیاز دارید؟
برای مثالهای مفصل به این بحث مراجعه کنید .
اگر هیچ موردی برای رفع مشکل پیدا نکردید، به ما اطلاع دهید که از چه دستور جستجویی استفاده کردهاید.
اصلاح جمعبندی نادرست برای استفادهngettext()
%dبا یافتن رشتههای قابل ترجمهای که شامل یک متغیر عددی ( or %i) هستند اما ()به جای از استفاده میکنند ، به بهبود پشتیبانی بینالمللیسازی (i18n) گیت کمک کنید Q(). این مهم است زیرا برخی از زبانها (مانند لهستانی) بیش از دو شکل جمع دارند و Q_()تنها راه صحیح برای مدیریت آنها همین است.
برای مثال، کلمه لهستانی «file» بسته به تعداد، شکل خود را تغییر میدهد:
۱ → پلیک
۲ - ۴ → پلیکی
۵ - ۲۱ → پلیکوو
۲۲ - ۲۴ → پلیکی
۲۵ - ۳۱ → پلیکوو
فراخوانی مانند این را ("Split into %d hunks.")نمیتوان برای همه شمارشها به درستی ترجمه کرد. باید با استفاده از Q()which که یک نام مستعار برای است، بازنویسی شود ngettext().
مراحل تکمیل
یافتن رشتههای کاندید با استفاده از:
git grep '[^Q]("[^"]%[id]' -- '.c'
نتایج را بررسی کنید و رشتههایی را شناسایی کنید که در آنها عدد واقعاً تعداد چیزها (هنکها، شاخهها، اشیاء و غیره) را کنترل میکند. Skip messages where %dبه چیزی اشاره دارد که هرگز جمع بسته نمیشود، مانند کد خطا، شماره خط یا مقدار timeout:
// NOT a pluralization candidate — error code is never "plural"
die_errno(("unable to get credential storage lock in %d ms"), timeout_ms);
// IS a candidate — hunk count should be pluralized
("Split into %d hunks.")
کاندید را با استفاده از موارد زیر بازنویسی کنید ngettext():
// Before:
printf(("Split into %d hunks."), n);
// After:
printf(Q_("Split into %d hunk.",
"Split into %d hunks.", n), n);
تستهای مربوطه را بسازید و اجرا کنید تا مطمئن شوید هیچ مشکلی وجود ندارد.
یادداشتها
یک فایل منبع با تعداد کمی نمونه انتخاب کنید تا پچ متمرکز و قابل بررسی باشد.
There are known candidates in add-patch.c, archive-zip.c, builtin/checkout.c, builtin/describe.c, builtin/fsck.c — so there should be plenty to choose from.
Each logical change (e.g., one function or one file) should ideally be its own commit.
Follow Git’s commit message conventions.
Before starting, ask on the mailing list to confirm no one else is working on the same file.
Need Help?
See the gettext manual on plural forms for background on why ngettext() is necessary.
Search the codebase for existing Q_() usages as examples of the correct pattern:
git grep -3 'Q_(' -- '*.c'
If you can’t find any unfixed instances, let us know the search command you used so we can retire this microproject idea.
Add more builtin patterns for userdiff
“git diff” shows the function name corresponding to each hunk after the @@ … @@ line. For common languages (C, HTML, Ada, Matlab, …), the way to find the function name is built-in Git’s source code as regular expressions (see userdiff.c). A few languages are common enough to deserve a built-in driver, but are not yet recognized. For example, shell.
This project requires a very good knowledge of regular expressions.
It is easy though to find examples of how this can be done by searching the code base and the mailing list archive, as this has already been done for a number of languages.
Avoid suppressing git’s exit code in test scripts
The Git project uses a large collection of integration tests written in Shell to guard against regressions when adding new features or fixing bugs. The scripts in question can be found in the t directory here.
While it is perfectly OK to use pipes when writing integration tests, we must be careful to avoid writing a pipeline that suppresses the exit code of a Git process, like so:
git |
…since the exit code of git would be suppressed by the pipe. If git crashed, we would not catch it in the above example when running the integration suite.
Other examples to avoid include:
bad:
$(git )
also bad:
<<EOF
... some text ...
$(git )
EOF
…since the exit code of git is hidden behind the subshell in both instances.
On the other hand, both of the following examples are OK, since neither hides the exit code of running git :
good:
var=$(git )
also good:
| | git
(provided that neither or are git).
See the commit c6f44e1da5 for example, and then do the same thing in one other test script.
If you can’t find one please tell us, along with the command you used to search, so that we can remove this microproject idea.
Modernize a test script
A number of our test scripts have been written a long time ago in a style that is now outdated.
In the following email it is explained in details how to modernize and clean up the t7001 test script:
https://lore.kernel.org/git/CAPig+cQpUu2UO-+jWn1nTaDykWnxwuEitzVB7PnW2SS_b7V8Hg@mail.gmail.com/
t7001 تنها اسکریپت آزمایشی نیست که میتوان تغییرات مشابهی را در آن اعمال کرد.
یک اسکریپت آزمایشی پیدا کنید که به برخی از همین تغییرات نیاز داشته باشد و آنها را اعمال کنید. لطفاً قبل از شروع کار روی آن، با درخواست از طریق فهرست پستی، مطمئن شوید که اسکریپت آزمایشی از قبل در حال کار نباشد.
فقط باید یک نوع تغییر در هر کامیت وجود داشته باشد. برای مثال، اگر یکی از کامیتهای شما به جای فاصله، بدنههای تست را با TAB توگذاری کرده باشد، این باید تنها نوع تغییر در این کامیت باشد.
یادداشتها
فقط روی t/t????-*.shاسکریپتها کار کنید.
فقط یک فیلمنامه انتخاب کنید (تا از پر شدن لیست نامزدهای دیگر جلوگیری شود).
هنگام تبدیل test -[def]به use test_path_exists()و siblings، فقط نمونههایی تبدیل میشوند که از نظر معنایی assertion (اظهارات) هستند (یعنی به عنوان بخشی از یک &&-chain استفاده میشوند).
منو"
"خانه
توسعه گیت
هک کردن گیت
فرآیند بازپرداخت هزینه سفر
اخبار گیت ریویو
درباره اخبار Git Rev
آخرین اخبار Git Rev
بایگانی اخبار Git Rev
منابع خبری Git Rev
مربیگری
اطلاعات عمومی درخواست
اطلاعات عمومی ریزپروژه
مطالب تاریخی SoC و اطلاعرسانی
راهنمای برنامه راهنمایی
مربیگری-SoC
ایدههای SoC 2026
ریزپروژههای متقاضی SoC 2026
شرکتکنندگان در SoC
راهنمایی-اطلاع رسانی
شرکتکنندگان در فعالیتهای ترویجی
مقدمه
ابتدا مطمئن شوید که دستورالعملها و پیشنهادهای کلی ما برای پروژههای خرد را خوانده و درک کردهاید .
در این سند، پیشنهادهایی برای چگونگی یافتن برخی از ریزپروژهها به تنهایی ارائه شده است.
ایدههایی برای پروژههای خرد
مدرنسازی بررسی مسیر تست در مجموعه تست گیت
با تبدیل بررسیهای مسیر قدیمی به توابع کمکی مدرن، به بهبود مجموعه تست گیت کمک کنید. ما دستورات تست پوسته پایه مانند را test -f با کمککنندههای تست اختصاصی گیت مانند test_path_is_file. جایگزین خواهیم کرد.
مراحل تکمیل
با استفاده از بررسیهای مسیر به سبک قدیمی، یک اسکریپت آزمایشی پیدا کنید:
git grep "test -[efd]" t/
به دنبال الگوهایی مانند موارد زیر باشید:
test -f path/to/file # old way
test_path_is_file path/to/file # new way
test -d some/directory # old way
test_path_is_dir some/directory # new way
مهم: فقط بررسیهایی را جایگزین کنید که واقعاً شرایط را آزمایش میکنند، نه آنهایی که در کنترل جریان استفاده میشوند. برای مثال:
DON'T change this - it's flow control
if test -e "file.txt"; then
do_something
fi
DO change this - it's a test assertion
test -e "file.txt" || error "file.txt should exist"
یادداشتها
از کوچک شروع کنید: یک فایل آزمایشی با تعداد کمی نمونه برای تبدیل انتخاب کنید
بعد از تغییرات، مجموعه تست را اجرا کنید تا مطمئن شوید هیچ مشکلی وجود ندارد
از سبک پیام کامیت گیت پیروی کنید
دستوری که برای پیدا کردن نمونهها استفاده کردید را در پیام کامیت خود ذکر کنید
به کمک نیاز دارید؟
برای مثالهای مفصل به این بحث مراجعه کنید .
اگر هیچ موردی برای رفع مشکل پیدا نکردید، به ما اطلاع دهید که از چه دستور جستجویی استفاده کردهاید.
اصلاح جمعبندی نادرست برای استفادهngettext()
%dبا یافتن رشتههای قابل ترجمهای که شامل یک متغیر عددی ( or %i) هستند اما ()به جای از استفاده میکنند ، به بهبود پشتیبانی بینالمللیسازی (i18n) گیت کمک کنید Q(). این مهم است زیرا برخی از زبانها (مانند لهستانی) بیش از دو شکل جمع دارند و Q_()تنها راه صحیح برای مدیریت آنها همین است.
برای مثال، کلمه لهستانی «file» بسته به تعداد، شکل خود را تغییر میدهد:
۱ → پلیک
۲ - ۴ → پلیکی
۵ - ۲۱ → پلیکوو
۲۲ - ۲۴ → پلیکی
۲۵ - ۳۱ → پلیکوو
فراخوانی مانند این را ("Split into %d hunks.")نمیتوان برای همه شمارشها به درستی ترجمه کرد. باید با استفاده از Q()which که یک نام مستعار برای است، بازنویسی شود ngettext().
مراحل تکمیل
یافتن رشتههای کاندید با استفاده از:
git grep '[^Q]("[^"]%[id]' -- '.c'
نتایج را بررسی کنید و رشتههایی را شناسایی کنید که در آنها عدد واقعاً تعداد چیزها (هنکها، شاخهها، اشیاء و غیره) را کنترل میکند. Skip messages where %dبه چیزی اشاره دارد که هرگز جمع بسته نمیشود، مانند کد خطا، شماره خط یا مقدار timeout:
// NOT a pluralization candidate — error code is never "plural"
die_errno(("unable to get credential storage lock in %d ms"), timeout_ms);
// IS a candidate — hunk count should be pluralized
("Split into %d hunks.")
کاندید را با استفاده از موارد زیر بازنویسی کنید ngettext():
// Before:
printf(("Split into %d hunks."), n);
// After:
printf(Q_("Split into %d hunk.",
"Split into %d hunks.", n), n);
تستهای مربوطه را بسازید و اجرا کنید تا مطمئن شوید هیچ مشکلی وجود ندارد.
یادداشتها
یک فایل منبع با تعداد کمی نمونه انتخاب کنید تا پچ متمرکز و قابل بررسی باشد.
There are known candidates in add-patch.c, archive-zip.c, builtin/checkout.c, builtin/describe.c, builtin/fsck.c — so there should be plenty to choose from.
Each logical change (e.g., one function or one file) should ideally be its own commit.
Follow Git’s commit message conventions.
Before starting, ask on the mailing list to confirm no one else is working on the same file.
Need Help?
See the gettext manual on plural forms for background on why ngettext() is necessary.
Search the codebase for existing Q_() usages as examples of the correct pattern:
git grep -3 'Q_(' -- '*.c'
If you can’t find any unfixed instances, let us know the search command you used so we can retire this microproject idea.
Add more builtin patterns for userdiff
“git diff” shows the function name corresponding to each hunk after the @@ … @@ line. For common languages (C, HTML, Ada, Matlab, …), the way to find the function name is built-in Git’s source code as regular expressions (see userdiff.c). A few languages are common enough to deserve a built-in driver, but are not yet recognized. For example, shell.
This project requires a very good knowledge of regular expressions.
It is easy though to find examples of how this can be done by searching the code base and the mailing list archive, as this has already been done for a number of languages.
Avoid suppressing git’s exit code in test scripts
The Git project uses a large collection of integration tests written in Shell to guard against regressions when adding new features or fixing bugs. The scripts in question can be found in the t directory here.
While it is perfectly OK to use pipes when writing integration tests, we must be careful to avoid writing a pipeline that suppresses the exit code of a Git process, like so:
git |
…since the exit code of git would be suppressed by the pipe. If git crashed, we would not catch it in the above example when running the integration suite.
Other examples to avoid include:
bad:
$(git )
also bad:
<<EOF
... some text ...
$(git )
EOF
…since the exit code of git is hidden behind the subshell in both instances.
On the other hand, both of the following examples are OK, since neither hides the exit code of running git :
good:
var=$(git )
also good:
| | git
(provided that neither or are git).
See the commit c6f44e1da5 for example, and then do the same thing in one other test script.
If you can’t find one please tell us, along with the command you used to search, so that we can remove this microproject idea.
Modernize a test script
A number of our test scripts have been written a long time ago in a style that is now outdated.
In the following email it is explained in details how to modernize and clean up the t7001 test script:
https://lore.kernel.org/git/CAPig+cQpUu2UO-+jWn1nTaDykWnxwuEitzVB7PnW2SS_b7V8Hg@mail.gmail.com/
t7001 تنها اسکریپت آزمایشی نیست که میتوان تغییرات مشابهی را در آن اعمال کرد.
یک اسکریپت آزمایشی پیدا کنید که به برخی از همین تغییرات نیاز داشته باشد و آنها را اعمال کنید. لطفاً قبل از شروع کار روی آن، با درخواست از طریق فهرست پستی، مطمئن شوید که اسکریپت آزمایشی از قبل در حال کار نباشد.
فقط باید یک نوع تغییر در هر کامیت وجود داشته باشد. برای مثال، اگر یکی از کامیتهای شما به جای فاصله، بدنههای تست را با TAB توگذاری کرده باشد، این باید تنها نوع تغییر در این کامیت باشد.
یادداشتها
فقط روی t/t????-*.shاسکریپتها کار کنید.
فقط یک فیلمنامه انتخاب کنید (تا از پر شدن لیست نامزدهای دیگر جلوگیری شود).
هنگام تبدیل test -[def]به use test_path_exists()و siblings، فقط نمونههایی تبدیل میشوند که از نظر معنایی assertion (اظهارات) هستند (یعنی به عنوان بخشی از یک &&-chain استفاده میشوند).
منو"
- - [ ] payammasroori57@gmail.com** @ **