1GIT-P4(1) Git Manual GIT-P4(1)
2
6 git-p4 - Import from and submit to Perforce repositories
7
9 git p4 clone [<sync options>] [<clone options>] <p4 depot path>...
10 git p4 sync [<sync options>] [<p4 depot path>...]
11 git p4 rebase
12 git p4 submit [<submit options>] [<master branch name>]
13
16 This command provides a way to interact with p4 repositories using Git.
17 Create a new Git repository from an existing p4 repository using git p4
19 clone, giving it one or more p4 depot paths. Incorporate new commits
20 from p4 changes with git p4 sync. The sync command is also used to
21 include new branches from other p4 depot paths. Submit Git changes back
22 to p4 using git p4 submit. The command git p4 rebase does a sync plus
23 rebases the current branch onto the updated p4 remote branch.
24
26 · Clone a repository:
27 $ git p4 clone //depot/path/project
29 · Do some work in the newly created Git repository:
32 $ cd project
34 $ vi foo.h
35 $ git commit -a -m "edited foo.h"
36 · Update the Git repository with recent changes from p4, rebasing
39 your work on top:
40 $ git p4 rebase
42 · Submit your commits back to p4:
45 $ git p4 submit
47
50 Clone
51 Generally, git p4 clone is used to create a new Git directory from an
52 existing p4 repository:
53 $ git p4 clone //depot/path/project
55 This:
58 1. Creates an empty Git repository in a subdirectory called project.
60 2. Imports the full contents of the head revision from the given p4
62 depot path into a single commit in the Git branch
63 refs/remotes/p4/master.
64 3. Creates a local branch, master from this remote and checks it out.
66 To reproduce the entire p4 history in Git, use the @all modifier on the
68 depot path:
69 $ git p4 clone //depot/path/project@all
71 Sync
74 As development continues in the p4 repository, those changes can be
75 included in the Git repository using:
76 $ git p4 sync
78 This command finds new changes in p4 and imports them as Git commits.
81 P4 repositories can be added to an existing Git repository using git p4
83 sync too:
84 $ mkdir repo-git
86 $ cd repo-git
87 $ git init
88 $ git p4 sync //path/in/your/perforce/depot
89 This imports the specified depot into refs/remotes/p4/master in an
92 existing Git repository. The --branch option can be used to specify a
93 different branch to be used for the p4 content.
94 If a Git repository includes branches refs/remotes/origin/p4, these
96 will be fetched and consulted first during a git p4 sync. Since
97 importing directly from p4 is considerably slower than pulling changes
98 from a Git remote, this can be useful in a multi-developer environment.
99 If there are multiple branches, doing git p4 sync will automatically
101 use the "BRANCH DETECTION" algorithm to try to partition new changes
102 into the right branch. This can be overridden with the --branch option
103 to specify just a single branch to update.
104 Rebase
106 A common working pattern is to fetch the latest changes from the p4
107 depot and merge them with local uncommitted changes. Often, the p4
108 repository is the ultimate location for all code, thus a rebase
109 workflow makes sense. This command does git p4 sync followed by git
110 rebase to move local commits on top of updated p4 changes.
111 $ git p4 rebase
113 Submit
116 Submitting changes from a Git repository back to the p4 repository
117 requires a separate p4 client workspace. This should be specified using
118 the P4CLIENT environment variable or the Git configuration variable
119 git-p4.client. The p4 client must exist, but the client root will be
120 created and populated if it does not already exist.
121 To submit all changes that are in the current Git branch but not in the
123 p4/master branch, use:
124 $ git p4 submit
126 To specify a branch other than the current one, use:
129 $ git p4 submit topicbranch
131 To specify a single commit or a range of commits, use:
134 $ git p4 submit --commit <sha1>
136 $ git p4 submit --commit <sha1..sha1>
137 The upstream reference is generally refs/remotes/p4/master, but can be
140 overridden using the --origin= command-line option.
141 The p4 changes will be created as the user invoking git p4 submit. The
143 --preserve-user option will cause ownership to be modified according to
144 the author of the Git commit. This option requires admin privileges in
145 p4, which can be granted using p4 protect.
146 To shelve changes instead of submitting, use --shelve and
148 --update-shelve:
149 $ git p4 submit --shelve
151 $ git p4 submit --update-shelve 1234 --update-shelve 2345
152 Unshelve
155 Unshelving will take a shelved P4 changelist, and produce the
156 equivalent git commit in the branch
157 refs/remotes/p4-unshelved/<changelist>.
158 The git commit is created relative to the current origin revision (HEAD
160 by default). A parent commit is created based on the origin, and then
161 the unshelve commit is created based on that.
162 The origin revision can be changed with the "--origin" option.
164 If the target branch in refs/remotes/p4-unshelved already exists, the
166 old one will be renamed.
167 $ git p4 sync
169 $ git p4 unshelve 12345
170 $ git show p4-unshelved/12345
171 <submit more changes via p4 to the same files>
172 $ git p4 unshelve 12345
173 <refuses to unshelve until git is in sync with p4 again>
174
177 General options
178 All commands except clone accept these options.
179 --git-dir <dir>
181 Set the GIT_DIR environment variable. See git(1).
182 -v, --verbose
184 Provide more progress information.
185 Sync options
187 These options can be used in the initial clone as well as in subsequent
188 sync operations.
189 --branch <ref>
191 Import changes into <ref> instead of refs/remotes/p4/master. If
192 <ref> starts with refs/, it is used as is. Otherwise, if it does
193 not start with p4/, that prefix is added.
194 By default a <ref> not starting with refs/ is treated as the name
196 of a remote-tracking branch (under refs/remotes/). This behavior
197 can be modified using the --import-local option.
198 The default <ref> is "master".
200 This example imports a new remote "p4/proj2" into an existing Git
202 repository:
203 $ git init
205 $ git p4 sync --branch=refs/remotes/p4/proj2 //depot/proj2
206 --detect-branches
209 Use the branch detection algorithm to find new paths in p4. It is
210 documented below in "BRANCH DETECTION".
211 --changesfile <file>
213 Import exactly the p4 change numbers listed in file, one per line.
214 Normally, git p4 inspects the current p4 repository state and
215 detects the changes it should import.
216 --silent
218 Do not print any progress information.
219 --detect-labels
221 Query p4 for labels associated with the depot paths, and add them
222 as tags in Git. Limited usefulness as only imports labels
223 associated with new changelists. Deprecated.
224 --import-labels
226 Import labels from p4 into Git.
227 --import-local
229 By default, p4 branches are stored in refs/remotes/p4/, where they
230 will be treated as remote-tracking branches by git-branch(1) and
231 other commands. This option instead puts p4 branches in
232 refs/heads/p4/. Note that future sync operations must specify
233 --import-local as well so that they can find the p4 branches in
234 refs/heads.
235 --max-changes <n>
237 Import at most n changes, rather than the entire range of changes
238 included in the given revision specifier. A typical usage would be
239 use @all as the revision specifier, but then to use --max-changes
240 1000 to import only the last 1000 revisions rather than the entire
241 revision history.
242 --changes-block-size <n>
244 The internal block size to use when converting a revision specifier
245 such as @all into a list of specific change numbers. Instead of
246 using a single call to p4 changes to find the full list of changes
247 for the conversion, there are a sequence of calls to p4 changes -m,
248 each of which requests one block of changes of the given size. The
249 default block size is 500, which should usually be suitable.
250 --keep-path
252 The mapping of file names from the p4 depot path to Git, by
253 default, involves removing the entire depot path. With this option,
254 the full p4 depot path is retained in Git. For example, path
255 //depot/main/foo/bar.c, when imported from //depot/main/, becomes
256 foo/bar.c. With --keep-path, the Git path is instead
257 depot/main/foo/bar.c.
258 --use-client-spec
260 Use a client spec to find the list of interesting files in p4. See
261 the "CLIENT SPEC" section below.
262 -/ <path>
264 Exclude selected depot paths when cloning or syncing.
265 Clone options
267 These options can be used in an initial clone, along with the sync
268 options described above.
269 --destination <directory>
271 Where to create the Git repository. If not provided, the last
272 component in the p4 depot path is used to create a new directory.
273 --bare
275 Perform a bare clone. See git-clone(1).
276 Submit options
278 These options can be used to modify git p4 submit behavior.
279 --origin <commit>
281 Upstream location from which commits are identified to submit to
282 p4. By default, this is the most recent p4 commit reachable from
283 HEAD.
284 -M
286 Detect renames. See git-diff(1). Renames will be represented in p4
287 using explicit move operations. There is no corresponding option to
288 detect copies, but there are variables for both moves and copies.
289 --preserve-user
291 Re-author p4 changes before submitting to p4. This option requires
292 p4 admin privileges.
293 --export-labels
295 Export tags from Git as p4 labels. Tags found in Git are applied to
296 the perforce working directory.
297 -n, --dry-run
299 Show just what commits would be submitted to p4; do not change
300 state in Git or p4.
301 --prepare-p4-only
303 Apply a commit to the p4 workspace, opening, adding and deleting
304 files in p4 as for a normal submit operation. Do not issue the
305 final "p4 submit", but instead print a message about how to submit
306 manually or revert. This option always stops after the first
307 (oldest) commit. Git tags are not exported to p4.
308 --shelve
310 Instead of submitting create a series of shelved changelists. After
311 creating each shelve, the relevant files are reverted/deleted. If
312 you have multiple commits pending multiple shelves will be created.
313 --update-shelve CHANGELIST
315 Update an existing shelved changelist with this commit. Implies
316 --shelve. Repeat for multiple shelved changelists.
317 --conflict=(ask|skip|quit)
319 Conflicts can occur when applying a commit to p4. When this
320 happens, the default behavior ("ask") is to prompt whether to skip
321 this commit and continue, or quit. This option can be used to
322 bypass the prompt, causing conflicting commits to be automatically
323 skipped, or to quit trying to apply commits, without prompting.
324 --branch <branch>
326 After submitting, sync this named branch instead of the default
327 p4/master. See the "Sync options" section above for more
328 information.
329 --commit <sha1>|<sha1..sha1>
331 Submit only the specified commit or range of commits, instead of
332 the full list of changes that are in the current Git branch.
333 --disable-rebase
335 Disable the automatic rebase after all commits have been
336 successfully submitted. Can also be set with git-p4.disableRebase.
337 --disable-p4sync
339 Disable the automatic sync of p4/master from Perforce after commits
340 have been submitted. Implies --disable-rebase. Can also be set with
341 git-p4.disableP4Sync. Sync with origin/master still goes ahead if
342 possible.
343 Hook for submit
345 The p4-pre-submit hook is executed if it exists and is executable. The
346 hook takes no parameters and nothing from standard input. Exiting with
347 non-zero status from this script prevents git-p4 submit from launching.
348 One usage scenario is to run unit tests in the hook.
350 Rebase options
352 These options can be used to modify git p4 rebase behavior.
353 --import-labels
355 Import p4 labels.
356 Unshelve options
358 --origin
359 Sets the git refspec against which the shelved P4 changelist is
360 compared. Defaults to p4/master.
361
363 The p4 depot path argument to git p4 sync and git p4 clone can be one
364 or more space-separated p4 depot paths, with an optional p4 revision
365 specifier on the end:
366 "//depot/my/project"
368 Import one commit with all files in the #head change under that
369 tree.
370 "//depot/my/project@all"
372 Import one commit for each change in the history of that depot
373 path.
374 "//depot/my/project@1,6"
376 Import only changes 1 through 6.
377 "//depot/proj1@all //depot/proj2@all"
379 Import all changes from both named depot paths into a single
380 repository. Only files below these directories are included. There
381 is not a subdirectory in Git for each "proj1" and "proj2". You must
382 use the --destination option when specifying more than one depot
383 path. The revision specifier must be specified identically on each
384 depot path. If there are files in the depot paths with the same
385 name, the path with the most recently updated version of the file
386 is the one that appears in Git.
387 See p4 help revisions for the full syntax of p4 revision specifiers.
389
391 The p4 client specification is maintained with the p4 client command
392 and contains among other fields, a View that specifies how the depot is
393 mapped into the client repository. The clone and sync commands can
394 consult the client spec when given the --use-client-spec option or when
395 the useClientSpec variable is true. After git p4 clone, the
396 useClientSpec variable is automatically set in the repository
397 configuration file. This allows future git p4 submit commands to work
398 properly; the submit command looks only at the variable and does not
399 have a command-line option.
400 The full syntax for a p4 view is documented in p4 help views. git p4
402 knows only a subset of the view syntax. It understands multi-line
403 mappings, overlays with +, exclusions with - and double-quotes around
404 whitespace. Of the possible wildcards, git p4 only handles ..., and
405 only when it is at the end of the path. git p4 will complain if it
406 encounters an unhandled wildcard.
407 Bugs in the implementation of overlap mappings exist. If multiple depot
409 paths map through overlays to the same location in the repository, git
410 p4 can choose the wrong one. This is hard to solve without dedicating a
411 client spec just for git p4.
412 The name of the client can be given to git p4 in multiple ways. The
414 variable git-p4.client takes precedence if it exists. Otherwise, normal
415 p4 mechanisms of determining the client are used: environment variable
416 P4CLIENT, a file referenced by P4CONFIG, or the local host name.
417
419 P4 does not have the same concept of a branch as Git. Instead, p4
420 organizes its content as a directory tree, where by convention
421 different logical branches are in different locations in the tree. The
422 p4 branch command is used to maintain mappings between different areas
423 in the tree, and indicate related content. git p4 can use these
424 mappings to determine branch relationships.
425 If you have a repository where all the branches of interest exist as
427 subdirectories of a single depot path, you can use --detect-branches
428 when cloning or syncing to have git p4 automatically find
429 subdirectories in p4, and to generate these as branches in Git.
430 For example, if the P4 repository structure is:
432 //depot/main/...
434 //depot/branch1/...
435 And "p4 branch -o branch1" shows a View line that looks like:
438 //depot/main/... //depot/branch1/...
440 Then this git p4 clone command:
443 git p4 clone --detect-branches //depot@all
445 produces a separate branch in refs/remotes/p4/ for //depot/main, called
448 master, and one for //depot/branch1 called depot/branch1.
449 However, it is not necessary to create branches in p4 to be able to use
451 them like branches. Because it is difficult to infer branch
452 relationships automatically, a Git configuration setting
453 git-p4.branchList can be used to explicitly identify branch
454 relationships. It is a list of "source:destination" pairs, like a
455 simple p4 branch specification, where the "source" and "destination"
456 are the path elements in the p4 repository. The example above relied on
457 the presence of the p4 branch. Without p4 branches, the same result
458 will occur with:
459 git init depot
461 cd depot
462 git config git-p4.branchList main:branch1
463 git p4 clone --detect-branches //depot@all .
464
467 The fast-import mechanism used by git p4 creates one pack file for each
468 invocation of git p4 sync. Normally, Git garbage compression (git-
469 gc(1)) automatically compresses these to fewer pack files, but explicit
470 invocation of git repack -adf may improve performance.
471
473 The following config settings can be used to modify git p4 behavior.
474 They all are in the git-p4 section.
475 General variables
477 git-p4.user
478 User specified as an option to all p4 commands, with -u <user>. The
479 environment variable P4USER can be used instead.
480 git-p4.password
482 Password specified as an option to all p4 commands, with -P
483 <password>. The environment variable P4PASS can be used instead.
484 git-p4.port
486 Port specified as an option to all p4 commands, with -p <port>. The
487 environment variable P4PORT can be used instead.
488 git-p4.host
490 Host specified as an option to all p4 commands, with -h <host>. The
491 environment variable P4HOST can be used instead.
492 git-p4.client
494 Client specified as an option to all p4 commands, with -c <client>,
495 including the client spec.
496 git-p4.retries
498 Specifies the number of times to retry a p4 command (notably, p4
499 sync) if the network times out. The default value is 3. Set the
500 value to 0 to disable retries or if your p4 version does not
501 support retries (pre 2012.2).
502 Clone and sync variables
504 git-p4.syncFromOrigin
505 Because importing commits from other Git repositories is much
506 faster than importing them from p4, a mechanism exists to find p4
507 changes first in Git remotes. If branches exist under
508 refs/remote/origin/p4, those will be fetched and used when syncing
509 from p4. This variable can be set to false to disable this
510 behavior.
511 git-p4.branchUser
513 One phase in branch detection involves looking at p4 branches to
514 find new ones to import. By default, all branches are inspected.
515 This option limits the search to just those owned by the single
516 user named in the variable.
517 git-p4.branchList
519 List of branches to be imported when branch detection is enabled.
520 Each entry should be a pair of branch names separated by a colon
521 (:). This example declares that both branchA and branchB were
522 created from main:
523 git config git-p4.branchList main:branchA
525 git config --add git-p4.branchList main:branchB
526 git-p4.ignoredP4Labels
529 List of p4 labels to ignore. This is built automatically as
530 unimportable labels are discovered.
531 git-p4.importLabels
533 Import p4 labels into git, as per --import-labels.
534 git-p4.labelImportRegexp
536 Only p4 labels matching this regular expression will be imported.
537 The default value is [a-zA-Z0-9_\-.]+$.
538 git-p4.useClientSpec
540 Specify that the p4 client spec should be used to identify p4 depot
541 paths of interest. This is equivalent to specifying the option
542 --use-client-spec. See the "CLIENT SPEC" section above. This
543 variable is a boolean, not the name of a p4 client.
544 git-p4.pathEncoding
546 Perforce keeps the encoding of a path as given by the originating
547 OS. Git expects paths encoded as UTF-8. Use this config to tell
548 git-p4 what encoding Perforce had used for the paths. This encoding
549 is used to transcode the paths to UTF-8. As an example, Perforce on
550 Windows often uses "cp1252" to encode path names.
551 git-p4.largeFileSystem
553 Specify the system that is used for large (binary) files. Please
554 note that large file systems do not support the git p4 submit
555 command. Only Git LFS is implemented right now (see
556 https://git-lfs.github.com/ for more information). Download and
557 install the Git LFS command line extension to use this option and
558 configure it like this:
559 git config git-p4.largeFileSystem GitLFS
561 git-p4.largeFileExtensions
564 All files matching a file extension in the list will be processed
565 by the large file system. Do not prefix the extensions with ..
566 git-p4.largeFileThreshold
568 All files with an uncompressed size exceeding the threshold will be
569 processed by the large file system. By default the threshold is
570 defined in bytes. Add the suffix k, m, or g to change the unit.
571 git-p4.largeFileCompressedThreshold
573 All files with a compressed size exceeding the threshold will be
574 processed by the large file system. This option might slow down
575 your clone/sync process. By default the threshold is defined in
576 bytes. Add the suffix k, m, or g to change the unit.
577 git-p4.largeFilePush
579 Boolean variable which defines if large files are automatically
580 pushed to a server.
581 git-p4.keepEmptyCommits
583 A changelist that contains only excluded files will be imported as
584 an empty commit if this boolean option is set to true.
585 git-p4.mapUser
587 Map a P4 user to a name and email address in Git. Use a string with
588 the following format to create a mapping:
589 git config --add git-p4.mapUser "p4user = First Last <mail@address.com>"
591 A mapping will override any user information from P4. Mappings for
593 multiple P4 user can be defined.
594 Submit variables
596 git-p4.detectRenames
597 Detect renames. See git-diff(1). This can be true, false, or a
598 score as expected by git diff -M.
599 git-p4.detectCopies
601 Detect copies. See git-diff(1). This can be true, false, or a score
602 as expected by git diff -C.
603 git-p4.detectCopiesHarder
605 Detect copies harder. See git-diff(1). A boolean.
606 git-p4.preserveUser
608 On submit, re-author changes to reflect the Git author, regardless
609 of who invokes git p4 submit.
610 git-p4.allowMissingP4Users
612 When preserveUser is true, git p4 normally dies if it cannot find
613 an author in the p4 user map. This setting submits the change
614 regardless.
615 git-p4.skipSubmitEdit
617 The submit process invokes the editor before each p4 change is
618 submitted. If this setting is true, though, the editing step is
619 skipped.
620 git-p4.skipSubmitEditCheck
622 After editing the p4 change message, git p4 makes sure that the
623 description really was changed by looking at the file modification
624 time. This option disables that test.
625 git-p4.allowSubmit
627 By default, any branch can be used as the source for a git p4
628 submit operation. This configuration variable, if set, permits only
629 the named branches to be used as submit sources. Branch names must
630 be the short names (no "refs/heads/"), and should be separated by
631 commas (","), with no spaces.
632 git-p4.skipUserNameCheck
634 If the user running git p4 submit does not exist in the p4 user
635 map, git p4 exits. This option can be used to force submission
636 regardless.
637 git-p4.attemptRCSCleanup
639 If enabled, git p4 submit will attempt to cleanup RCS keywords
640 ($Header$, etc). These would otherwise cause merge conflicts and
641 prevent the submit going ahead. This option should be considered
642 experimental at present.
643 git-p4.exportLabels
645 Export Git tags to p4 labels, as per --export-labels.
646 git-p4.labelExportRegexp
648 Only p4 labels matching this regular expression will be exported.
649 The default value is [a-zA-Z0-9_\-.]+$.
650 git-p4.conflict
652 Specify submit behavior when a conflict with p4 is found, as per
653 --conflict. The default behavior is ask.
654 git-p4.disableRebase
656 Do not rebase the tree against p4/master following a submit.
657 git-p4.disableP4Sync
659 Do not sync p4/master with Perforce following a submit. Implies
660 git-p4.disableRebase.
661
663 · Changesets from p4 are imported using Git fast-import.
664 · Cloning or syncing does not require a p4 client; file contents are
666 collected using p4 print.
667 · Submitting requires a p4 client, which is not in the same location
669 as the Git repository. Patches are applied, one at a time, to this
670 p4 client and submitted from there.
671 · Each commit imported by git p4 has a line at the end of the log
673 message indicating the p4 depot location and change number. This
674 line is used by later git p4 sync operations to know which p4
675 changes are new.
676Git 2.20.1 12/15/2018 GIT-P4(1)