'\" t
.\" Title: git-p4
.\" Author: [FIXME: author] [see http://www.docbook.org/tdg5/en/html/author]
.\" Generator: DocBook XSL Stylesheets vsnapshot
.\" Date: 2026-06-29
.\" Manual: راهنمای گیت
.\" Source: Git 2.55.0
.\" Language: Persian
.\"
.TH "GIT\-P4" "1" "2026\-06\-29" "Git 2\&.55\&.0" "راهنمای گیت"
.\" -----------------------------------------------------------------
.\" * Define some portability stuff
.\" -----------------------------------------------------------------
.\" ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
.\" http://bugs.debian.org/507673
.\" http://lists.gnu.org/archive/html/groff/2009-02/msg00013.html
.\" ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
.ie \n(.g .ds Aq \(aq
.el .ds Aq '
.\" -----------------------------------------------------------------
.\" * set default formatting
.\" -----------------------------------------------------------------
.\" disable hyphenation
.nh
.\" disable justification (adjust text to left margin only)
.ad l
.\" -----------------------------------------------------------------
.\" * MAIN CONTENT STARTS HERE *
.\" -----------------------------------------------------------------
.SH "نام (NAME)"
git-p4 \- وارد کردن از و ارسال به مخازن Perforce
.SH "خلاصه دستور (SYNOPSIS)"
.sp
.nf
\fIgit p4 clone\fR [<گزینه‌های\-همگام‌سازی>] [<گزینه‌های\-شبیه‌سازی>] <مسیر\-انبار\-p4>\&...
\fIgit p4 sync\fR [<گزینه‌های\-همگام‌سازی>] [<مسیر\-انبار\-p4>\&...]
\fIgit p4 rebase\fR
\fIgit p4 submit\fR [<گزینه‌های\-ارسال>] [<نام\-شاخه\-اصلی>]
.fi
.sp
.SH "توضیحات (DESCRIPTION)"
.sp
این دستور راهکاری برای تعامل با مخازن p4 با استفاده از گیت فراهم می‌کند\&.
.sp
با استفاده از \fIgit p4 clone\fR و دادن یک یا چند مسیر انبار (depot) p4 به آن، یک مخزن گیت جدید از یک مخزن موجود p4 بسازید\&. کامیت‌های جدید ناشی از تغییرات p4 را با استفاده از \fIgit p4 sync\fR ادغام و وارد کنید\&. دستور \fIsync\fR همچنین برای افزودن شاخه‌های جدید از سایر مسیرهای انبار p4 استفاده می‌شود\&. تغییرات گیت را با استفاده از \fIgit p4 submit\fR به p4 برگردانید و ارسال کنید\&. دستور \fIgit p4 rebase\fR یک عملیات sync به علاوه بازنشانی پایه (rebase) شاخه کنونی روی شاخه دوردست به‌روزشدهٔ p4 انجام می‌دهد\&.
.SH "مثال‌ها (EXAMPLES)"
.sp
.RS 4
.ie n \{\
\h'-04'\(bu\h'+03'\c
.\}
.el \{\
.sp -1
.IP \(bu 2.3
.\}
شبیه‌سازی یک مخزن:
.sp
.if n \{\
.RS 4
.\}
.nf
$ git p4 clone //depot/path/project
.fi
.if n \{\
.RE
.\}
.sp
.RE
.sp
.RS 4
.ie n \{\
\h'-04'\(bu\h'+03'\c
.\}
.el \{\
.sp -1
.IP \(bu 2.3
.\}
انجام مقداری کار در مخزن گیت تازه ایجاد شده:
.sp
.if n \{\
.RS 4
.\}
.nf
$ cd project
$ vi foo\&.h
$ git commit \-a \-m "edited foo\&.h"
.fi
.if n \{\
.RE
.\}
.sp
.RE
.sp
.RS 4
.ie n \{\
\h'-04'\(bu\h'+03'\c
.\}
.el \{\
.sp -1
.IP \(bu 2.3
.\}
به‌روزرسانی مخزن گیت با تغییرات اخیر از p4، و بازنشانی پایهٔ (rebase) کار شما روی آن:
.sp
.if n \{\
.RS 4
.\}
.nf
$ git p4 rebase
.fi
.if n \{\
.RE
.\}
.sp
.RE
.sp
.RS 4
.ie n \{\
\h'-04'\(bu\h'+03'\c
.\}
.el \{\
.sp -1
.IP \(bu 2.3
.\}
ارسال کامیت‌های شما به p4:
.sp
.if n \{\
.RS 4
.\}
.nf
$ git p4 submit
.fi
.if n \{\
.RE
.\}
.sp
.RE
.SH "دستورها (COMMANDS)"
.SS "شبیه‌سازی (Clone)"
.sp
به طور کلی، \fIgit p4 clone\fR برای ایجاد یک دایرکتوری گیت جدید از یک مخزن موجود p4 استفاده می‌شود:
.sp
.if n \{\
.RS 4
.\}
.nf
$ git p4 clone //depot/path/project
.fi
.if n \{\
.RE
.\}
.sp
.sp
این کار:
.sp
.RS 4
.ie n \{\
\h'-04' 1.\h'+01'\c
.\}
.el \{\
.sp -1
.IP " 1." 4.2
.\}
یک مخزن خالی گیت در یک زیردایرکتوری به نام
\fIproject\fR
ایجاد می‌کند\&.
.RE
.sp
.RS 4
.ie n \{\
\h'-04' 2.\h'+01'\c
.\}
.el \{\
.sp -1
.IP " 2." 4.2
.\}
محتوای کامل نسخهٔ سر (head revision) را از مسیر انبار p4 داده‌شده به صورت یک تک‌کامیت در شاخه گیت
\fIrefs/remotes/p4/master\fR
وارد می‌کند\&.
.RE
.sp
.RS 4
.ie n \{\
\h'-04' 3.\h'+01'\c
.\}
.el \{\
.sp -1
.IP " 3." 4.2
.\}
یک شاخه محلی به نام
\fImaster\fR
از این شاخهٔ دوردست ایجاد کرده و آن را تحویل (checkout) می‌گیرد\&.
.RE
.sp
برای بازتولید تمام تاریخچه p4 در گیت، از تغییردهندهٔ \fI@all\fR در مسیر انبار استفاده کنید:
.sp
.if n \{\
.RS 4
.\}
.nf
$ git p4 clone //depot/path/project@all
.fi
.if n \{\
.RE
.\}
.sp
.SS "همگام‌سازی (Sync)"
.sp
همان‌طور که توسعه در مخزن p4 ادامه می‌یابد، آن تغییرات را می‌توان با استفاده از دستور زیر در مخزن گیت گنجاند:
.sp
.if n \{\
.RS 4
.\}
.nf
$ git p4 sync
.fi
.if n \{\
.RE
.\}
.sp
.sp
این دستور تغییرات جدید را در p4 پیدا کرده و آن‌ها را به عنوان کامیت‌های گیت وارد می‌کند\&.
.sp
مخازن p4 را می‌توان با استفاده از \fIgit p4 sync\fR به یک مخزن موجود گیت نیز افزود:
.sp
.if n \{\
.RS 4
.\}
.nf
$ mkdir repo\-git
$ cd repo\-git
$ git init
$ git p4 sync //path/in/your/perforce/depot
.fi
.if n \{\
.RE
.\}
.sp
.sp
این کار انبار مشخص‌شده را در \fIrefs/remotes/p4/master\fR در یک مخزن موجود گیت وارد می‌کند\&. گزینهٔ \fB\-\-branch\fR می‌تواند برای تعیین یک شاخهٔ متفاوت جهت استفاده برای محتوای p4 به کار رود\&.
.sp
اگر یک مخزن گیت شامل شاخه‌های \fIrefs/remotes/origin/p4\fR باشد، این شاخه‌ها در طول یک عملیات \fIgit p4 sync\fR ابتدا واکشی شده و مورد ارجاع قرار می‌گیرند\&. از آنجا که وارد کردن مستقیم از p4 به مراتب کندتر از واکشی تغییرات از یک مخزن دوردست گیت است، این قابلیت می‌تواند در یک محیط با چند توسعه‌دهنده مفید باشد\&.
.sp
اگر چندین شاخه وجود داشته باشد، اجرای \fIgit p4 sync\fR به طور خودکار از الگوریتم «تشخیص شاخه» (BRANCH DETECTION) برای تلاش جهت تفکیک تغییرات جدید به شاخه درست استفاده می‌کند\&. این رفتار را می‌توان با گزینهٔ \fB\-\-branch\fR لغو کرد تا تنها یک شاخه برای به‌روزرسانی مشخص شود\&.
.SS "تغییر پایه (Rebase)"
.sp
یک الگوی کاری رایج، واکشی آخرین تغییرات از انبار p4 و ادغام آن‌ها با تغییرات محلی ثبت‌نشده (uncommitted) است\&. اغلب اوقات، مخزن p4 مکان نهایی تمام کدها است، از این رو یک گردش کار بازنشانی پایه (rebase) منطقی به نظر می‌رسد\&. این دستور یک \fIgit p4 sync\fR و به دنبال آن یک \fIgit rebase\fR را اجرا می‌کند تا کامیت‌های محلی را به بالای تغییرات به‌روزشدهٔ p4 منتقل کند\&.
.sp
.if n \{\
.RS 4
.\}
.nf
$ git p4 rebase
.fi
.if n \{\
.RE
.\}
.sp
.SS "ارسال (Submit)"
.sp
ارسال تغییرات از یک مخزن گیت به مخزن p4 نیازمند یک فضای کاری کلاینت (client workspace) مجزای p4 است\&. این مورد باید با استفاده از متغیر محیطی \fBP4CLIENT\fR یا متغیر پیکربندی گیت \fIgit\-p4\&.client\fR مشخص شود\&. کلاینت p4 باید وجود داشته باشد، اما اگر ریشه کلاینت (client root) هنوز وجود نداشته باشد، ایجاد شده و فایل‌ها در آن پر می‌شوند\&.
.sp
برای ارسال تمام تغییراتی که در شاخه فعلی گیت هستند اما در شاخهٔ \fIp4/master\fR نیستند، از دستور زیر استفاده کنید:
.sp
.if n \{\
.RS 4
.\}
.nf
$ git p4 submit
.fi
.if n \{\
.RE
.\}
.sp
.sp
برای مشخص کردن شاخه‌ای غیر از شاخه فعلی، از دستور زیر استفاده کنید:
.sp
.if n \{\
.RS 4
.\}
.nf
$ git p4 submit topicbranch
.fi
.if n \{\
.RE
.\}
.sp
.sp
برای مشخص کردن یک کامیت منفرد یا یک محدوده از کامیت‌ها، از دستور زیر استفاده کنید:
.sp
.if n \{\
.RS 4
.\}
.nf
$ git p4 submit \-\-commit
$ git p4 submit \-\-commit
.fi
.if n \{\
.RE
.\}
.sp
.sp
مرجع بالادستی (upstream reference) به طور کلی \fIrefs/remotes/p4/master\fR است، اما می‌تواند با استفاده از گزینهٔ خط فرمان \fB\-\-origin=\fR بازنویسی شود\&.
.sp
تغییرات p4 با هویت کاربری که \fIgit p4 submit\fR را اجرا می‌کند ایجاد خواهند شد\&. گزینهٔ \fB\-\-preserve\-user\fR باعث می‌شود مالکیت با توجه به پدیدآورندهٔ (author) کامیت گیت تغییر یابد\&. این گزینه نیازمند دسترسی‌های مدیر در p4 است که می‌تواند با استفاده از \fIp4 protect\fR اعطا شود\&.
.sp
برای قفسه‌بندی (shelve / تعلیق موقت) تغییرات به جای ارسال، از \fB\-\-shelve\fR و \fB\-\-update\-shelve\fR استفاده کنید:
.sp
.if n \{\
.RS 4
.\}
.nf
$ git p4 submit \-\-shelve
$ git p4 submit \-\-update\-shelve 1234 \-\-update\-shelve 2345
.fi
.if n \{\
.RE
.\}
.sp
.SS "خروج از قفسه (Unshelve)"
.sp
عملیات Unshelving یک لیست تغییرات (changelist) تعلیق‌شده در P4 را دریافت کرده و کامیت معادل گیت را در شاخهٔ refs/remotes/p4\-unshelved/ تولید می‌کند\&.
.sp
کامیت گیت نسبت به نسخه مبدا فعلی (به طور پیش‌فرض HEAD) ایجاد می‌شود\&. یک کامیت والد بر اساس مبدا ایجاد شده و سپس کامیت unshelve بر اساس آن ساخته می‌شود\&.
.sp
نسخه مبدا را می‌توان با گزینهٔ "\-\-origin" تغییر داد\&.
.sp
اگر شاخه هدف در refs/remotes/p4\-unshelved از قبل وجود داشته باشد، شاخه قدیمی تغییر نام خواهد یافت\&.
.sp
.if n \{\
.RS 4
.\}
.nf
$ git p4 sync
$ git p4 unshelve 12345
$ git show p4\-unshelved/12345
$ git p4 unshelve 12345
.fi
.if n \{\
.RE
.\}
.sp
.SH "گزینه‌ها (OPTIONS)"
.SS "گزینه‌های عمومی (General options)"
.sp
همه دستورها به جز clone این گزینه‌ها را می‌پذیرند\&.
.PP
\-\-git\-dir
.RS 4
تنظیم متغیر محیطی
\fBGIT_DIR\fR\&.
راهنمای
\fBgit\fR(1)
را ببینید\&.
.RE
.PP
\-v, \-\-verbose
.RS 4
ارائه اطلاعات بیشتر درباره روند پیشرفت\&.
.RE
.SS "گزینه‌های همگام‌سازی (Sync options)"
.sp
این گزینه‌ها را می‌توان در \fIclone\fR اولیه و همچنین در عملیات‌های بعدی \fIsync\fR استفاده کرد\&.
.PP
\-\-branch [
.RS 4
وارد کردن تغییرات به ][ به جای refs/remotes/p4/master\&. اگر ][ با refs/ آغاز شود، همان‌طور که هست استفاده می‌شود\&. در غیر این صورت، اگر با p4/ آغاز نشود، این پیشوند به آن افزوده می‌شود\&.
.sp
به طور پیش‌فرض، یک ][ که با refs/ آغاز نشود به عنوان نام یک شاخه ردیابی دوردست (تحت refs/remotes/) در نظر گرفته می‌شود\&. این رفتار را می‌توان با استفاده از گزینهٔ \-\-import\-local تغییر داد\&.
.sp
مقدار پیش‌فرض ][ برابر "master" است\&.
.sp
این مثال یک شاخه دوردست جدید "p4/proj2" را به یک مخزن موجود گیت وارد می‌کند:
.sp
.if n \{\
.RS 4
.\}
.nf
$ git init
$ git p4 sync \-\-branch=refs/remotes/p4/proj2 //depot/proj2
.fi
.if n \{\
.RE
.\}
.sp
.RE
.PP
\-\-detect\-branches
.RS 4
استفاده از الگوریتم تشخیص شاخه برای یافتن مسیرهای جدید در p4\&. در بخش "تشخیص شاخه (BRANCH DETECTION)" در زیر مستند شده است\&.
.RE
.PP
\-\-changesfile
.RS 4
وارد کردن دقیقاً همان شماره تغییرات p4 که در
\fIfile\fR
فهرست شده‌اند، در هر خط یکی\&. به طور معمول،
\fIgit p4\fR
وضعیت کنونی مخزن p4 را بررسی کرده و تغییراتی را که باید وارد شوند تشخیص می‌دهد\&.
.RE
.PP
\-\-silent
.RS 4
عدم چاپ هرگونه اطلاعات پیشرفت\&.
.RE
.PP
\-\-detect\-labels
.RS 4
پرس‌وجو از p4 برای برچسب‌های (labels) مرتبط با مسیرهای انبار، و افزودن آن‌ها به عنوان تگ (tag) در گیت\&. به دلیل آنکه تنها برچسب‌های مرتبط با changelistهای جدید را وارد می‌کند کاربرد محدودی دارد\&. منسوخ شده است\&.
.RE
.PP
\-\-import\-labels
.RS 4
وارد کردن برچسب‌ها از p4 به گیت\&.
.RE
.PP
\-\-import\-local
.RS 4
به طور پیش‌فرض، شاخه‌های p4 در
\fIrefs/remotes/p4/\fR
ذخیره می‌شوند، جایی که توسط
\fBgit-branch\fR(1)
و سایر دستورات به عنوان شاخه‌های ردیابی دوردست (remote\-tracking) در نظر گرفته خواهند شد\&. این گزینه در عوض شاخه‌های p4 را در
\fIrefs/heads/p4/\fR
قرار می‌دهد\&. توجه داشته باشید که عملیات‌های همگام‌سازی آینده نیز باید
\fB\-\-import\-local\fR
را مشخص کنند تا بتوانند شاخه‌های p4 را در refs/heads بیابند\&.
.RE
.PP
\-\-max\-changes
.RS 4
وارد کردن حداکثر
\fIn\fR
تغییر، به جای کل بازه تغییرات موجود در شناسه نسخه داده‌شده\&. یک کاربرد معمول استفاده از
\fI@all\fR
به عنوان مشخص‌کننده نسخه، اما سپس استفاده از
\fI\-\-max\-changes 1000\fR
برای وارد کردن تنها ۱۰۰۰ نسخه آخر به جای کل تاریخچه نسخه‌ها خواهد بود\&.
.RE
.PP
\-\-changes\-block\-size
.RS 4
اندازه بلوک داخلی برای استفاده هنگام تبدیل یک مشخص‌کننده نسخه مانند
\fI@all\fR
به فهرستی از شماره‌های تغییر خاص\&. به جای استفاده از یک فراخوانی منفرد به
\fIp4 changes\fR
برای یافتن فهرست کامل تغییرات جهت تبدیل، دنباله‌ای از فراخوانی‌ها به
\fIp4 changes \-m\fR
انجام می‌شود که هر کدام یک بلوک از تغییرات را به اندازه داده‌شده درخواست می‌کند\&. اندازه بلوک پیش‌فرض ۵۰۰ است که معمولاً مناسب است\&.
.RE
.PP
\-\-keep\-path
.RS 4
نگاشت نام فایل‌ها از مسیر انبار p4 به گیت به طور پیش‌فرض شامل حذف کل مسیر انبار است\&. با این گزینه، مسیر کامل انبار p4 در گیت حفظ می‌شود\&. برای مثال، مسیر
\fI//depot/main/foo/bar\&.c\fR،
هنگامی که از
\fI//depot/main/\fR
وارد می‌شود، به
\fIfoo/bar\&.c\fR
تبدیل می‌شود\&. با
\fB\-\-keep\-path\fR،
مسیر در گیت به جای آن برابر
\fIdepot/main/foo/bar\&.c\fR
خواهد بود\&.
.RE
.PP
\-\-use\-client\-spec
.RS 4
استفاده از یک مشخصات کلاینت (client spec) برای یافتن فهرست فایل‌های مورد نظر در p4\&. بخش "مشخصات کلاینت (CLIENT SPEC)" را در زیر ببینید\&.
.RE
.PP
\-/
.RS 4
مستثنی کردن مسیرهای انبار انتخاب‌شده هنگام شبیه‌سازی یا همگام‌سازی\&.
.RE
.SS "گزینه‌های شبیه‌سازی (Clone options)"
.sp
این گزینه‌ها را می‌توان در یک \fIclone\fR اولیه به همراه گزینه‌های \fIsync\fR که در بالا توضیح داده شدند استفاده کرد\&.
.PP
\-\-destination
.RS 4
محل ایجاد مخزن گیت\&. در صورت ارائه نشدن، آخرین مولفه در مسیر انبار p4 برای ایجاد یک دایرکتوری جدید استفاده می‌شود\&.
.RE
.PP
\-\-bare
.RS 4
انجام یک شبیه‌سازی خام (bare clone)\&. راهنمای
\fBgit-clone\fR(1)
را ببینید\&.
.RE
.SS "گزینه‌های ارسال (Submit options)"
.sp
این گزینه‌ها می‌توانند برای اصلاح رفتار \fIgit p4 submit\fR استفاده شوند\&.
.PP
\-\-origin
.RS 4
مکان بالادستی که کامیت‌ها از آن برای ارسال به p4 شناسایی می‌شوند\&. به طور پیش‌فرض، این جدیدترین کامیت p4 قابل دستیابی از
\fBHEAD\fR
است\&.
.RE
.PP
\-M
.RS 4
تشخیص تغییر نام‌ها\&. راهنمای
\fBgit-diff\fR(1)
را ببینید\&. تغییر نام‌ها در p4 با استفاده از عملیات‌های صریح
\fImove\fR
نمایش داده خواهند شد\&. گزینه متناظری برای تشخیص کپی‌ها وجود ندارد، اما متغیرهایی برای هر دو مورد جابه‌جایی و کپی وجود دارد\&.
.RE
.PP
\-\-preserve\-user
.RS 4
بازنویسی پدیدآورنده تغییرات p4 پیش از ارسال به p4\&. این گزینه نیازمند دسترسی‌های مدیر در p4 است\&.
.RE
.PP
\-\-export\-labels
.RS 4
صادر کردن تگ‌ها از گیت به عنوان برچسب‌های p4\&. تگ‌های یافت‌شده در گیت بر روی دایرکتوری کاری perforce اعمال می‌شوند\&.
.RE
.PP
\-n, \-\-dry\-run
.RS 4
تنها نشان دادن اینکه چه کامیت‌هایی به p4 ارسال خواهند شد؛ وضعیت را در گیت یا p4 تغییر ندهید\&.
.RE
.PP
\-\-prepare\-p4\-only
.RS 4
اعمال یک کامیت روی فضای کاری p4، با باز کردن، افزودن و حذف فایل‌ها در p4 همانند یک عملیات عادی submit\&. اما دستور نهایی "p4 submit" صادر نمی‌شود، بلکه در عوض پیامی درباره نحوه ارسال دستی یا بازگرداندن (revert) چاپ می‌شود\&. این گزینه همیشه پس از اولین (قدیمی‌ترین) کامیت متوقف می‌شود\&. تگ‌های گیت به p4 صادر نمی‌شوند\&.
.RE
.PP
\-\-shelve
.RS 4
به جای ارسال، ایجاد مجموعه‌ای از فهرست‌های تغییرات تعلیق‌شده (shelved changelists)\&. پس از ایجاد هر shelve، فایل‌های مربوطه بازگردانی/حذف (reverted/deleted) می‌شوند\&. اگر چندین کامیت در انتظار داشته باشید، چندین shelve ایجاد خواهد شد\&.
.RE
.PP
\-\-update\-shelve CHANGELIST
.RS 4
به‌روزرسانی یک لیست تغییرات تعلیق‌شدهٔ موجود با این کامیت\&. مستلزم گزینه \-\-shelve است\&. برای چندین changelist تعلیق‌شده تکرار کنید\&.
.RE
.PP
\-\-conflict=(ask|skip|quit)
.RS 4
هنگام اعمال یک کامیت روی p4 ممکن است تعارض رخ دهد\&. وقتی این اتفاق می‌افتد، رفتار پیش‌فرض ("ask") این است که سوال شود آیا این کامیت نادیده گرفته شده و ادامه یابد، یا خارج شود\&. این گزینه می‌تواند برای دور زدن این اعلان استفاده شود و باعث شود کامیت‌های دارای تعارض به طور خودکار نادیده گرفته شوند، یا اینکه تلاش برای اعمال کامیت‌ها بدون درخواست تایید متوقف گردد\&.
.RE
.PP
\-\-branch
.RS 4
پس از ارسال، همگام‌سازی این شاخه نام‌گذاری‌شده به جای شاخه پیش‌فرض p4/master\&. برای اطلاعات بیشتر بخش "گزینه‌های همگام‌سازی (Sync options)" در بالا را ببینید\&.
.RE
.PP
\-\-commit (|\&.\&.)
.RS 4
تنها ارسال کامیت یا محدوده کامیت‌های مشخص‌شده، به جای فهرست کامل تغییراتی که در شاخه فعلی گیت وجود دارد\&.
.RE
.PP
\-\-disable\-rebase
.RS 4
غیرفعال کردن بازنشانی پایه خودکار پس از اینکه تمام کامیت‌ها با موفقیت ارسال شدند\&. همچنین می‌تواند با git\-p4\&.disableRebase تنظیم شود\&.
.RE
.PP
\-\-disable\-p4sync
.RS 4
غیرفعال کردن همگام‌سازی خودکار p4/master از Perforce پس از ارسال کامیت‌ها\&. مستلزم گزینه \-\-disable\-rebase است\&. همچنین می‌تواند با git\-p4\&.disableP4Sync تنظیم شود\&. همگام‌سازی با origin/master در صورت امکان همچنان انجام می‌شود\&.
.RE
.SH "قلاب‌ها برای ارسال (HOOKS FOR SUBMIT)"
.SS "p4\-pre\-submit"
.sp
قلاب \fBp4\-pre\-submit\fR در صورت وجود و قابل اجرا بودن اجرا می‌شود\&. این قلاب هیچ پارامتری دریافت نمی‌کند و هیچ چیزی از ورودی استاندارد نمی‌گیرد\&. خروج با وضعیت غیر صفر از این اسکریپت مانع از اجرای \fBgit\-p4\fR \fBsubmit\fR می‌شود\&. این قلاب را می‌توان با گزینه خط فرمان \fB\-\-no\-verify\fR دور زد\&.
.sp
یک سناریوی کاربردی اجرای آزمون‌های واحد (unit tests) در این قلاب است\&.
.SS "p4\-prepare\-changelist"
.sp
قلاب \fBp4\-prepare\-changelist\fR درست پس از آماده‌سازی پیام پیش‌فرض changelist و قبل از شروع ویرایشگر اجرا می‌شود\&. این قلاب یک پارامتر دریافت می‌کند که نام فایلی است که متن changelist را در بر دارد\&. خروج با وضعیت غیر صفر از اسکریپت فرآیند را متوقف خواهد کرد\&.
.sp
هدف از این قلاب، ویرایش درجا (in place) فایل پیام است و با گزینه \fB\-\-no\-verify\fR غیرفعال نمی‌شود\&. این قلاب حتی در صورت تنظیم \fB\-\-prepare\-p4\-only\fR نیز فراخوانی می‌شود\&.
.SS "p4\-changelist"
.sp
قلاب \fBp4\-changelist\fR پس از اینکه پیام changelist توسط کاربر ویرایش شد اجرا می‌شود\&. این قلاب می‌تواند با گزینه \fB\-\-no\-verify\fR دور زده شود\&. این قلاب یک پارامتر واحد دریافت می‌کند که نام فایلی است که متن پیشنهادی changelist را نگه‌داری می‌کند\&. خروج با وضعیت غیر صفر باعث لغو دستور می‌شود\&.
.sp
این قلاب مجاز به ویرایش فایل changelist است و می‌تواند برای یکدست‌سازی متن به قالبی استاندارد در پروژه استفاده شود\&. همچنین می‌تواند پس از بازبینی فایل پیام، برای رد کردن Submit استفاده شود\&.
.SS "p4\-post\-changelist"
.sp
قلاب \fBp4\-post\-changelist\fR پس از اینکه ارسال با موفقیت در P4 انجام شد فراخوانی می‌شود\&. هیچ پارامتری دریافت نمی‌کند و اساساً برای اطلاع‌رسانی در نظر گرفته شده است و نمی‌تواند بر نتیجه عملیات git p4 submit تأثیر بگذارد\&.
.SS "گزینه‌های تغییر پایه (Rebase options)"
.sp
این گزینه‌ها می‌توانند برای تغییر رفتار \fIgit p4 rebase\fR استفاده شوند\&.
.PP
\-\-import\-labels
.RS 4
وارد کردن برچسب‌های p4\&.
.RE
.SS "گزینه‌های خروج از قفسه (Unshelve options)"
.PP
\-\-origin
.RS 4
تنظیم refspec گیت که changelist تعلیق‌شده در P4 در برابر آن مقایسه می‌شود\&. پیش‌فرض p4/master است\&.
.RE
.SH "نحو مسیر انبار (DEPOT PATH SYNTAX)"
.sp
آرگومان مسیر انبار p4 به \fIgit p4 sync\fR و \fIgit p4 clone\fR می‌تواند یک یا چند مسیر انبار p4 جداشده با فاصله باشد، همراه با یک شناسه نسخه اختیاری p4 در انتها:
.PP
"//depot/my/project"
.RS 4
وارد کردن یک کامیت با تمام فایل‌ها در تغییر
\fI#head\fR
تحت آن درخت\&.
.RE
.PP
"//depot/my/project@all"
.RS 4
وارد کردن یک کامیت به ازای هر تغییر در تاریخچه آن مسیر انبار\&.
.RE
.PP
"//depot/my/project@1,6"
.RS 4
تنها وارد کردن تغییرات ۱ تا ۶\&.
.RE
.PP
"//depot/proj1@all //depot/proj2@all"
.RS 4
وارد کردن تمام تغییرات از هر دو مسیر انبار نام‌برده‌شده در یک مخزن واحد\&. تنها فایل‌های زیر این دایرکتوری‌ها گنجانده می‌شوند\&. در گیت برای هر کدام از "proj1" و "proj2" یک زیردایرکتوری ایجاد نمی‌شود\&. هنگام مشخص کردن بیش از یک مسیر انبار، باید از گزینهٔ
\fB\-\-destination\fR
استفاده کنید\&. مشخص‌کننده نسخه باید روی هر مسیر انبار به طور یکسان تعیین شود\&. اگر در مسیرهای انبار فایل‌هایی با نام یکسان وجود داشته باشد، مسیری که جدیدترین نسخه به‌روزشدهٔ فایل را دارد در گیت ظاهر می‌شود\&.
.RE
.sp
برای نحو کامل مشخص‌کننده‌های نسخه در p4، به \fIp4 help revisions\fR مراجعه کنید\&.
.SH "مشخصات کلاینت (CLIENT SPEC)"
.sp
مشخصات کلاینت p4 با دستور \fIp4 client\fR نگه‌داری می‌شود و از جمله فیلدهای دیگر، شامل یک View است که مشخص می‌کند چگونه انبار به مخزن کلاینت نگاشت می‌شود\&. دستورهای \fIclone\fR و \fIsync\fR می‌توانند هنگام دریافت گزینهٔ \fB\-\-use\-client\-spec\fR یا زمانی که متغیر useClientSpec برابر true است، مشخصات کلاینت را مد نظر قرار دهند\&. پس از \fIgit p4 clone\fR، متغیر useClientSpec به طور خودکار در فایل پیکربندی مخزن تنظیم می‌شود\&. این کار اجازه می‌دهد دستورهای آیندهٔ \fIgit p4 submit\fR به درستی کار کنند؛ دستور submit تنها به این متغیر نگاه می‌کند و گزینه خط فرمانی برای آن ندارد\&.
.sp
نحو کامل برای یک view در p4 در \fIp4 help views\fR مستند شده است\&. \fIgit p4\fR تنها زیرمجموعه‌ای از نحو view را می‌شناسد\&. این ابزار نگاشت‌های چندخطی، همپوشانی‌ها (overlays) با \fI+\fR، موارد استثنا با \fI\-\fR و علامت نقل‌قول دوگانه در اطراف فاصله‌ها را متوجه می‌شود\&. از میان نویسه‌های عمومی (wildcards) ممکن، \fIgit p4\fR تنها \fI\&...\fR را مدیریت می‌کند، و آن هم فقط زمانی که در انتهای مسیر باشد\&. اگر \fIgit p4\fR با نویسه عمومی پشتیبانی‌نشده‌ای مواجه شود، خطا گزارش می‌دهد\&.
.sp
اشکالاتی در پیاده‌سازی نگاشت‌های دارای همپوشانی وجود دارد\&. اگر چندین مسیر انبار از طریق overlays به یک مکان یکسان در مخزن نگاشت شوند، \fIgit p4\fR ممکن است مسیر اشتباه را انتخاب کند\&. حل این مشکل بدون اختصاص یک مشخصات کلاینت صرفاً برای \fIgit p4\fR دشوار است\&.
.sp
نام کلاینت را می‌توان به روش‌های مختلفی به \fIgit p4\fR ارائه کرد\&. متغیر \fIgit\-p4\&.client\fR در صورت وجود اولویت دارد\&. در غیر این صورت، سازوکارهای عادی p4 برای تعیین کلاینت استفاده می‌شوند: متغیر محیطی \fBP4CLIENT\fR، یک فایل ارجاع داده‌شده توسط \fBP4CONFIG\fR، یا نام میزبان محلی (local host name)\&.
.SH "تشخیص شاخه (BRANCH DETECTION)"
.sp
نرم‌افزار P4 مفهومی یکسان با شاخه در گیت ندارد\&. در عوض، p4 محتوای خود را به صورت یک درخت دایرکتوری سازماندهی می‌کند که بر اساس توافق، شاخه‌های منطقی مختلف در مکان‌های متفاوتی در درخت قرار دارند\&. دستور \fIp4 branch\fR برای نگه‌داری نگاشت‌های میان بخش‌های مختلف در درخت و نشان دادن محتوای مرتبط استفاده می‌شود\&. \fIgit p4\fR می‌تواند از این نگاشت‌ها برای تعیین روابط شاخه‌ها استفاده کند\&.
.sp
اگر مخزنی دارید که در آن تمام شاخه‌های مورد نظر به عنوان زیردایرکتوری‌های یک مسیر انبار واحد وجود دارند، می‌توانید هنگام شبیه‌سازی یا همگام‌سازی از \fB\-\-detect\-branches\fR استفاده کنید تا \fIgit p4\fR به طور خودکار زیردایرکتوری‌ها را در p4 پیدا کرده و آن‌ها را به عنوان شاخه‌هایی در گیت ایجاد کند\&.
.sp
برای مثال، اگر ساختار مخزن P4 به صورت زیر باشد:
.sp
.if n \{\
.RS 4
.\}
.nf
//depot/main/\&.\&.\&.
//depot/branch1/\&.\&.\&.
.fi
.if n \{\
.RE
.\}
.sp
.sp
و دستور "p4 branch \-o branch1" یک خط View را نشان دهد که شبیه زیر است:
.sp
.if n \{\
.RS 4
.\}
.nf
//depot/main/\&.\&.\&. //depot/branch1/\&.\&.\&.
.fi
.if n \{\
.RE
.\}
.sp
.sp
سپس این دستور \fIgit p4 clone\fR:
.sp
.if n \{\
.RS 4
.\}
.nf
git p4 clone \-\-detect\-branches //depot@all
.fi
.if n \{\
.RE
.\}
.sp
.sp
یک شاخهٔ جداگانه در \fIrefs/remotes/p4/\fR برای //depot/main به نام \fImaster\fR، و یک شاخه برای //depot/branch1 به نام \fIdepot/branch1\fR تولید می‌کند\&.
.sp
با این حال، برای اینکه بتوان از آن‌ها مانند شاخه‌ها استفاده کرد، ایجاد شاخه‌ها در p4 الزامی نیست\&. از آنجا که استنباط روابط شاخه‌ها به طور خودکار دشوار است، می‌توان از تنظیم پیکربندی گیت \fIgit\-p4\&.branchList\fR برای شناسایی صریح روابط شاخه‌ها استفاده کرد\&. این تنظیم فهرستی از جفت‌های "source:destination" است، مانند یک مشخصات ساده شاخه در p4، که در آن "source" و "destination" عناصر مسیر در مخزن p4 هستند\&. مثال بالا متکی به حضور شاخه p4 بود\&. بدون شاخه‌های p4، همین نتیجه با دستورهای زیر حاصل خواهد شد:
.sp
.if n \{\
.RS 4
.\}
.nf
git init depot
cd depot
git config git\-p4\&.branchList main:branch1
git p4 clone \-\-detect\-branches //depot@all \&.
.fi
.if n \{\
.RE
.\}
.sp
.SH "کارایی (PERFORMANCE)"
.sp
سازوکار fast\-import مورد استفاده توسط \fIgit p4\fR برای هر بار فراخوانی \fIgit p4 sync\fR یک pack file ایجاد می‌کند\&. معمولاً فشرده‌سازی بازیافت حافظه گیت (\fBgit-gc\fR(1)) به طور خودکار این فایل‌ها را به بسته‌های کمتری فشرده می‌کند، اما اجرای صریح دستور \fIgit repack \-adf\fR ممکن است کارایی را بهبود بخشد\&.
.SH "متغیرهای پیکربندی (CONFIGURATION VARIABLES)"
.sp
تنظیمات پیکربندی زیر می‌توانند برای تغییر رفتار \fIgit p4\fR استفاده شوند\&. همه آن‌ها در بخش \fIgit\-p4\fR قرار دارند\&.
.SS "متغیرهای عمومی (General variables)"
.PP
git\-p4\&.user
.RS 4
کاربر مشخص‌شده به عنوان گزینه‌ای برای همه دستورهای p4، با
\fI\-u \fR\&.
متغیر محیطی
\fBP4USER\fR
می‌تواند به جای آن استفاده شود\&.
.RE
.PP
git\-p4\&.password
.RS 4
گذرواژه مشخص‌شده به عنوان گزینه‌ای برای همه دستورهای p4، با
\fI\-P \fR\&.
متغیر محیطی
\fBP4PASS\fR
می‌تواند به جای آن استفاده شود\&.
.RE
.PP
git\-p4\&.port
.RS 4
درگاه (پورت) مشخص‌شده به عنوان گزینه‌ای برای همه دستورهای p4، با
\fI\-p \fR\&.
متغیر محیطی
\fBP4PORT\fR
می‌تواند به جای آن استفاده شود\&.
.RE
.PP
git\-p4\&.host
.RS 4
میزبان مشخص‌شده به عنوان گزینه‌ای برای همه دستورهای p4، با
\fI\-h \fR\&.
متغیر محیطی
\fBP4HOST\fR
می‌تواند به جای آن استفاده شود\&.
.RE
.PP
git\-p4\&.client
.RS 4
کلاینت مشخص‌شده به عنوان گزینه‌ای برای همه دستورهای p4، با
\fI\-c \fR،
شامل مشخصات کلاینت\&.
.RE
.PP
git\-p4\&.retries
.RS 4
تعداد دفعات تلاش مجدد برای یک دستور p4 (به ویژه
\fIp4 sync\fR)
را در صورت اتمام مهلت شبکه مشخص می‌کند\&. مقدار پیش‌فرض ۳ است\&. برای غیرفعال کردن تلاش‌های مجدد یا در صورتی که نسخه p4 شما از تلاش مجدد پشتیبانی نمی‌کند (قبل از 2012.2)، مقدار را روی 0 تنظیم کنید\&.
.RE
.SS "متغیرهای شبیه‌سازی و همگام‌سازی (Clone and sync variables)"
.PP
git\-p4\&.syncFromOrigin
.RS 4
از آنجا که وارد کردن کامیت‌ها از سایر مخازن گیت بسیار سریع‌تر از وارد کردن آن‌ها از p4 است، سازوکاری برای یافتن تغییرات p4 ابتدا در شاخه‌های دوردست گیت وجود دارد\&. اگر شاخه‌هایی تحت
\fIrefs/remote/origin/p4\fR
وجود داشته باشند، هنگام همگام‌سازی از p4 واکشی شده و استفاده خواهند شد\&. این متغیر می‌تواند برای غیرفعال کردن این رفتار بر روی
\fIfalse\fR
تنظیم شود\&.
.RE
.PP
git\-p4\&.branchUser
.RS 4
یک مرحله در تشخیص شاخه شامل بررسی شاخه‌های p4 برای یافتن شاخه‌های جدید جهت وارد کردن است\&. به طور پیش‌فرض، تمام شاخه‌ها بررسی می‌شوند\&. این گزینه جستجو را تنها به مواردی محدود می‌کند که متعلق به کاربری هستند که نامش در متغیر ذکر شده است\&.
.RE
.PP
git\-p4\&.branchList
.RS 4
فهرست شاخه‌هایی که هنگام فعال بودن تشخیص شاخه باید وارد شوند\&. هر ورودی باید یک جفت از نام‌های شاخه باشد که با دونقطه (:) از هم جدا شده‌اند\&. این مثال اعلام می‌کند که هر دو شاخه branchA و branchB از main ایجاد شده‌اند:
.sp
.if n \{\
.RS 4
.\}
.nf
git config git\-p4\&.branchList main:branchA
git config \-\-add git\-p4\&.branchList main:branchB
.fi
.if n \{\
.RE
.\}
.sp
.RE
.PP
git\-p4\&.ignoredP4Labels
.RS 4
فهرست برچسب‌های p4 برای نادیده گرفتن\&. این فهرست با کشف برچسب‌های غیرقابل وارد کردن به طور خودکار ساخته می‌شود\&.
.RE
.PP
git\-p4\&.importLabels
.RS 4
وارد کردن برچسب‌های p4 به گیت، مطابق با \-\-import\-labels\&.
.RE
.PP
git\-p4\&.labelImportRegexp
.RS 4
تنها برچسب‌های p4 که با این عبارت باقاعده مطابقت دارند وارد خواهند شد\&. مقدار پیش‌فرض برابر است با
\fI[a\-zA\-Z0\-9_\e\-\&.]+$\fR\&.
.RE
.PP
git\-p4\&.useClientSpec
.RS 4
مشخص می‌کند که مشخصات کلاینت p4 باید برای شناسایی مسیرهای انبار مورد نظر p4 استفاده شود\&. این معادل تعیین گزینهٔ
\fB\-\-use\-client\-spec\fR
است\&. بخش "مشخصات کلاینت (CLIENT SPEC)" را در بالا ببینید\&. این متغیر یک مقدار بولی است، نه نام یک کلاینت p4\&.
.RE
.PP
git\-p4\&.pathEncoding
.RS 4
سیستم Perforce کدگذاری یک مسیر را همان‌طور که توسط سیستم‌عامل مبدا تعیین شده نگه‌داری می‌کند\&. گیت انتظار دارد مسیرها با کدگذاری UTF\-8 باشند\&. از این پیکربندی برای اعلام به git\-p4 استفاده کنید که Perforce از چه کدگذاری‌ای برای مسیرها استفاده کرده است\&. این کدگذاری برای تبدیل مسیرها به UTF\-8 استفاده می‌شود\&. به عنوان مثال، Perforce در ویندوز اغلب از "cp1252" برای کدگذاری نام مسیرها استفاده می‌کند\&. اگر این گزینه به درخواست p4 clone ارسال شود، در مخزن گیت جدید حاصل ذخیره و ماندگار می‌شود\&.
.RE
.PP
git\-p4\&.metadataDecodingStrategy
.RS 4
سیستم Perforce کدگذاری توضیحات changelist و نام کامل کاربران را همان‌طور که توسط کلاینت در یک سیستم‌عامل ذخیره شده حفظ می‌کند\&. کلاینت p4v از کدگذاری محلی سیستم‌عامل استفاده می‌کند، بنابراین کاربران مختلف ممکن است در نهایت توضیحات changelist یا نام‌های کامل متفاوتی را با کدگذاری‌های متفاوتی در همان انبار ذخیره کنند\&. گیت کدگذاری‌های ناهماهنگ/نادرست را در پیام‌های کامیت و نام نویسندگان تحمل می‌کند، اما انتظار دارد آن‌ها در قالب utf\-8 مشخص شوند\&. ابزار git\-p4 می‌تواند از سه راهبرد مختلف رمزگشایی در مواجهه با عدم قطعیت کدگذاری در Perforce استفاده کند:
\fIpassthrough\fR
صرفاً بایت‌های اصلی را از Perforce به گیت منتقل می‌کند و در صورتی که داده‌های Perforce با چیزی غیر از utf\-8 کدگذاری شده باشند، داده‌هایی قابل استفاده اما با کدگذاری نادرست ایجاد می‌کند\&.
\fIstrict\fR
انتظار دارد داده‌های Perforce با کدگذاری utf\-8 باشند، و در غیر این صورت عملیات وارد کردن با شکست مواجه می‌شود\&.
\fIfallback\fR
تلاش می‌کند داده‌ها را به عنوان utf\-8 تفسیر کند، و در غیر این صورت به استفاده از یک کدگذاری ثانویه بازمی‌گردد \- به طور پیش‌فرض کدگذاری رایج ویندوز
\fIcp\-1252\fR
\- که در صورت عدم موفقیت در رمزگشایی با کدگذاری پشتیبان، بایت‌های دامنه بالایی اسکیپ می‌شوند\&. در پایتون ۲ راهبرد پیش‌فرض به دلایل تاریخی
\fIpassthrough\fR
است، و در پایتون ۳ پیش‌فرض
\fIfallback\fR
است\&. هنگامی که
\fIstrict\fR
انتخاب شود و رمزگشایی با شکست مواجه گردد، پیام خطا تغییر این پارامتر پیکربندی را به عنوان راهکار پیشنهاد می‌دهد\&. اگر این گزینه به درخواست p4 clone ارسال شود، در مخزن گیت جدید حاصل ذخیره می‌شود\&.
.RE
.PP
git\-p4\&.metadataFallbackEncoding
.RS 4
کدگذاری پشتیبان (fallback) مورد استفاده هنگام رمزگشایی نام نویسندگان و توضیحات changelist در Perforce با استفاده از راهبرد
\fIfallback\fR
را مشخص می‌کند (نگاه کنید به git\-p4\&.metadataDecodingStrategy)\&. کدگذاری پشتیبان تنها زمانی استفاده خواهد شد که رمزگشایی به عنوان utf\-8 با شکست مواجه شود\&. این گزینه به طور پیش‌فرض روی cp1252، یک کدگذاری رایج ویندوز، تنظیم است\&. اگر این گزینه به درخواست p4 clone ارسال شود، در مخزن گیت جدید حاصل ذخیره می‌شود\&.
.RE
.PP
git\-p4\&.largeFileSystem
.RS 4
سیستم مورد استفاده برای فایل‌های بزرگ (باینری) را مشخص می‌کند\&. لطفاً توجه داشته باشید که سیستم‌های فایل بزرگ از دستور
\fIgit p4 submit\fR
پشتیبانی نمی‌کنند\&. در حال حاضر تنها Git LFS پیاده‌سازی شده است (برای اطلاعات بیشتر به
\m[blue]\fBhttps://git\-lfs\&.github\&.com\fR\m[]
مراجعه کنید)\&. برای استفاده از این گزینه، افزونه خط فرمان Git LFS را دانلود و نصب کرده و آن را به این صورت پیکربندی نمایید:
.sp
.if n \{\
.RS 4
.\}
.nf
git config git\-p4\&.largeFileSystem GitLFS
.fi
.if n \{\
.RE
.\}
.sp
.RE
.PP
git\-p4\&.largeFileExtensions
.RS 4
تمام فایل‌هایی که با یک پسوند فایل در این فهرست مطابقت دارند توسط سیستم فایل‌های بزرگ پردازش خواهند شد\&. پیشوند
\fI\&.\fR
را به پسوندها اضافه نکنید\&.
.RE
.PP
git\-p4\&.largeFileThreshold
.RS 4
تمام فایل‌هایی که اندازه غیرفشرده آن‌ها از آستانه فراتر رود توسط سیستم فایل‌های بزرگ پردازش خواهند شد\&. به طور پیش‌فرض این آستانه بر حسب بایت تعریف می‌شود\&. پسوند k یا m یا g را برای تغییر واحد اضافه کنید\&.
.RE
.PP
git\-p4\&.largeFileCompressedThreshold
.RS 4
تمام فایل‌هایی که اندازه فشرده آن‌ها از آستانه فراتر رود توسط سیستم فایل‌های بزرگ پردازش خواهند شد\&. این گزینه ممکن است روند شبیه‌سازی/همگام‌سازی شما را کند کند\&. به طور پیش‌فرض آستانه بر حسب بایت تعریف می‌شود\&. پسوند k یا m یا g را برای تغییر واحد اضافه کنید\&.
.RE
.PP
git\-p4\&.largeFilePush
.RS 4
متغیر بولی که تعیین می‌کند آیا فایل‌های بزرگ به طور خودکار به سرور ارسال (push) شوند یا خیر\&.
.RE
.PP
git\-p4\&.keepEmptyCommits
.RS 4
اگر این گزینه بولی روی true تنظیم شود، یک changelist که تنها شامل فایل‌های مستثنی‌شده است به عنوان یک کامیت خالی وارد خواهد شد\&.
.RE
.PP
git\-p4\&.mapUser
.RS 4
نگاشت یک کاربر P4 به یک نام و نشانی ایمیل در گیت\&. از یک رشته با قالب زیر برای ایجاد نگاشت استفاده کنید:
.sp
.if n \{\
.RS 4
.\}
.nf
git config \-\-add git\-p4\&.mapUser "p4user = First Last "
.fi
.if n \{\
.RE
.\}
.sp
یک نگاشت هرگونه اطلاعات کاربر از P4 را لغو خواهد کرد\&. نگاشت‌ها را می‌توان برای چندین کاربر P4 تعریف کرد\&.
.RE
.SS "متغیرهای ارسال (Submit variables)"
.PP
git\-p4\&.detectRenames
.RS 4
تشخیص تغییر نام‌ها\&. راهنمای
\fBgit-diff\fR(1)
را ببینید\&. این می‌تواند true یا false یا یک امتیاز مورد انتظار توسط
\fIgit diff \-M\fR
باشد\&.
.RE
.PP
git\-p4\&.detectCopies
.RS 4
تشخیص کپی‌ها\&. راهنمای
\fBgit-diff\fR(1)
را ببینید\&. این می‌تواند true یا false یا یک امتیاز مورد انتظار توسط
\fIgit diff \-C\fR
باشد\&.
.RE
.PP
git\-p4\&.detectCopiesHarder
.RS 4
تشخیص دقیق‌تر کپی‌ها\&. راهنمای
\fBgit-diff\fR(1)
را ببینید\&. یک مقدار بولی است\&.
.RE
.PP
git\-p4\&.preserveUser
.RS 4
هنگام ارسال، تغییرات را بازنویسی کنید تا نویسنده گیت را منعکس کند، صرف‌نظر از اینکه چه کسی
\fIgit p4 submit\fR
را اجرا می‌کند\&.
.RE
.PP
git\-p4\&.allowMissingP4Users
.RS 4
هنگامی که
\fIpreserveUser\fR
برابر true باشد،
\fIgit p4\fR
به طور معمول اگر نتواند نویسنده‌ای را در نقشه کاربران p4 پیدا کند متوقف می‌شود\&. این تنظیم در هر صورت تغییرات را ارسال می‌کند\&.
.RE
.PP
git\-p4\&.skipSubmitEdit
.RS 4
فرآیند submit ویرایشگر را قبل از ارسال هر تغییر p4 فراخوانی می‌کند\&. با این حال، اگر این تنظیم برابر true باشد، مرحله ویرایش نادیده گرفته می‌شود\&.
.RE
.PP
git\-p4\&.skipSubmitEditCheck
.RS 4
پس از ویرایش پیام تغییر p4،
\fIgit p4\fR
با بررسی زمان تغییر فایل اطمینان حاصل می‌کند که توضیحات واقعاً تغییر کرده است\&. این گزینه آن آزمایش را غیرفعال می‌کند\&.
.RE
.PP
git\-p4\&.allowSubmit
.RS 4
به طور پیش‌فرض، هر شاخه‌ای می‌تواند به عنوان منبع برای یک عملیات
\fIgit p4 submit\fR
استفاده شود\&. این متغیر پیکربندی، در صورت تنظیم، تنها به شاخه‌های نام‌برده اجازه می‌دهد به عنوان منابع ارسال استفاده شوند\&. نام شاخه‌ها باید نام‌های کوتاه باشند (بدون "refs/heads/") و باید با کاما (",") و بدون فاصله از هم جدا شوند\&.
.RE
.PP
git\-p4\&.skipUserNameCheck
.RS 4
اگر کاربری که
\fIgit p4 submit\fR
را اجرا می‌کند در نقشه کاربران p4 وجود نداشته باشد،
\fIgit p4\fR
خارج می‌شود\&. این گزینه می‌تواند برای اجبار به ارسال در هر صورت استفاده شود\&.
.RE
.PP
git\-p4\&.attemptRCSCleanup
.RS 4
در صورت فعال بودن،
\fIgit p4 submit\fR
تلاش خواهد کرد کلیدواژه‌های RCS مانند ($Header$ و غیره) را پاکسازی کند\&. در غیر این صورت این موارد باعث تعارض ادغام شده و مانع از انجام ارسال می‌شوند\&. این گزینه در حال حاضر باید آزمایشی در نظر گرفته شود\&.
.RE
.PP
git\-p4\&.exportLabels
.RS 4
صادر کردن تگ‌های گیت به برچسب‌های p4، مطابق با \-\-export\-labels\&.
.RE
.PP
git\-p4\&.labelExportRegexp
.RS 4
تنها برچسب‌های p4 که با این عبارت باقاعده مطابقت دارند صادر خواهند شد\&. مقدار پیش‌فرض برابر است با
\fI[a\-zA\-Z0\-9_\e\-\&.]+$\fR\&.
.RE
.PP
git\-p4\&.conflict
.RS 4
مشخص کردن رفتار submit هنگام یافتن تعارض با p4، مطابق با \-\-conflict\&. رفتار پیش‌فرض برابر است با
\fIask\fR\&.
.RE
.PP
git\-p4\&.disableRebase
.RS 4
پس از یک ارسال، شاخه را در برابر p4/master بازنشانی پایه نکنید\&.
.RE
.PP
git\-p4\&.disableP4Sync
.RS 4
پس از ارسال، p4/master را با Perforce همگام‌سازی نکنید\&. مستلزم git\-p4\&.disableRebase است\&. همگام‌سازی با origin/master در صورت امکان همچنان انجام می‌شود\&.
.RE
.SH "جزئیات پیاده‌سازی (IMPLEMENTATION DETAILS)"
.sp
.RS 4
.ie n \{\
\h'-04'\(bu\h'+03'\c
.\}
.el \{\
.sp -1
.IP \(bu 2.3
.\}
مجموعه‌تغییرات (changesets) از p4 با استفاده از Git fast\-import وارد می‌شوند\&.
.RE
.sp
.RS 4
.ie n \{\
\h'-04'\(bu\h'+03'\c
.\}
.el \{\
.sp -1
.IP \(bu 2.3
.\}
شبیه‌سازی یا همگام‌سازی نیازی به کلاینت p4 ندارد؛ محتویات فایل با استفاده از
\fIp4 print\fR
جمع‌آوری می‌شوند\&.
.RE
.sp
.RS 4
.ie n \{\
\h'-04'\(bu\h'+03'\c
.\}
.el \{\
.sp -1
.IP \(bu 2.3
.\}
ارسال (Submit) نیازمند کلاینت p4 است، که در همان مکان مخزن گیت قرار ندارد\&. وصله‌ها (patches) یکی‌یکی بر روی این کلاینت p4 اعمال شده و از آنجا ارسال می‌شوند\&.
.RE
.sp
.RS 4
.ie n \{\
\h'-04'\(bu\h'+03'\c
.\}
.el \{\
.sp -1
.IP \(bu 2.3
.\}
هر کامیت واردشده توسط
\fIgit p4\fR
یک خط در انتهای پیام لاگ دارد که مکان انبار p4 و شماره تغییر را نشان می‌دهد\&. این خط توسط عملیات‌های بعدی
\fIgit p4 sync\fR
استفاده می‌شود تا مشخص شود کدام تغییرات p4 جدید هستند\&.
.RE
.SH "همچنین ببینید (SEE ALSO)"
.sp
\fBgit\fR(1),
\fBgit\-branch\fR(1),
\fBgit\-clone\fR(1),
\fBgit\-diff\fR(1)
.SH "گیت (GIT)"
.sp
بخشی از مجموعه \fBgit\fR(1)]