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 The upstream reference is generally refs/remotes/p4/master, but can be
134 overridden using the --origin= command-line option.
135 The p4 changes will be created as the user invoking git p4 submit. The
137 --preserve-user option will cause ownership to be modified according to
138 the author of the Git commit. This option requires admin privileges in
139 p4, which can be granted using p4 protect.
140
142 General options
143 All commands except clone accept these options.
144 --git-dir <dir>
146 Set the GIT_DIR environment variable. See git(1).
147 --verbose, -v
149 Provide more progress information.
150 Sync options
152 These options can be used in the initial clone as well as in subsequent
153 sync operations.
154 --branch <branch>
156 Import changes into given branch. If the branch starts with refs/,
157 it will be used as is. Otherwise if it does not start with p4/,
158 that prefix is added. The branch is assumed to name a remote
159 tracking, but this can be modified using --import-local, or by
160 giving a full ref name. The default branch is master.
161 This example imports a new remote "p4/proj2" into an existing Git
163 repository:
164 $ git init
166 $ git p4 sync --branch=refs/remotes/p4/proj2 //depot/proj2
167 --detect-branches
170 Use the branch detection algorithm to find new paths in p4. It is
171 documented below in "BRANCH DETECTION".
172 --changesfile <file>
174 Import exactly the p4 change numbers listed in file, one per line.
175 Normally, git p4 inspects the current p4 repository state and
176 detects the changes it should import.
177 --silent
179 Do not print any progress information.
180 --detect-labels
182 Query p4 for labels associated with the depot paths, and add them
183 as tags in Git. Limited usefulness as only imports labels
184 associated with new changelists. Deprecated.
185 --import-labels
187 Import labels from p4 into Git.
188 --import-local
190 By default, p4 branches are stored in refs/remotes/p4/, where they
191 will be treated as remote-tracking branches by git-branch(1) and
192 other commands. This option instead puts p4 branches in
193 refs/heads/p4/. Note that future sync operations must specify
194 --import-local as well so that they can find the p4 branches in
195 refs/heads.
196 --max-changes <n>
198 Limit the number of imported changes to n. Useful to limit the
199 amount of history when using the @all p4 revision specifier.
200 --keep-path
202 The mapping of file names from the p4 depot path to Git, by
203 default, involves removing the entire depot path. With this option,
204 the full p4 depot path is retained in Git. For example, path
205 //depot/main/foo/bar.c, when imported from //depot/main/, becomes
206 foo/bar.c. With --keep-path, the Git path is instead
207 depot/main/foo/bar.c.
208 --use-client-spec
210 Use a client spec to find the list of interesting files in p4. See
211 the "CLIENT SPEC" section below.
212 Clone options
214 These options can be used in an initial clone, along with the sync
215 options described above.
216 --destination <directory>
218 Where to create the Git repository. If not provided, the last
219 component in the p4 depot path is used to create a new directory.
220 --bare
222 Perform a bare clone. See git-clone(1).
223 -/ <path>
225 Exclude selected depot paths when cloning.
226 Submit options
228 These options can be used to modify git p4 submit behavior.
229 --origin <commit>
231 Upstream location from which commits are identified to submit to
232 p4. By default, this is the most recent p4 commit reachable from
233 HEAD.
234 -M
236 Detect renames. See git-diff(1). Renames will be represented in p4
237 using explicit move operations. There is no corresponding option to
238 detect copies, but there are variables for both moves and copies.
239 --preserve-user
241 Re-author p4 changes before submitting to p4. This option requires
242 p4 admin privileges.
243 --export-labels
245 Export tags from Git as p4 labels. Tags found in Git are applied to
246 the perforce working directory.
247 --dry-run, -n
249 Show just what commits would be submitted to p4; do not change
250 state in Git or p4.
251 --prepare-p4-only
253 Apply a commit to the p4 workspace, opening, adding and deleting
254 files in p4 as for a normal submit operation. Do not issue the
255 final "p4 submit", but instead print a message about how to submit
256 manually or revert. This option always stops after the first
257 (oldest) commit. Git tags are not exported to p4.
258 --conflict=(ask|skip|quit)
260 Conflicts can occur when applying a commit to p4. When this
261 happens, the default behavior ("ask") is to prompt whether to skip
262 this commit and continue, or quit. This option can be used to
263 bypass the prompt, causing conflicting commits to be automatically
264 skipped, or to quit trying to apply commits, without prompting.
265 --branch <branch>
267 After submitting, sync this named branch instead of the default
268 p4/master. See the "Sync options" section above for more
269 information.
270 Rebase options
272 These options can be used to modify git p4 rebase behavior.
273 --import-labels
275 Import p4 labels.
276
278 The p4 depot path argument to git p4 sync and git p4 clone can be one
279 or more space-separated p4 depot paths, with an optional p4 revision
280 specifier on the end:
281 "//depot/my/project"
283 Import one commit with all files in the #head change under that
284 tree.
285 "//depot/my/project@all"
287 Import one commit for each change in the history of that depot
288 path.
289 "//depot/my/project@1,6"
291 Import only changes 1 through 6.
292 "//depot/proj1@all //depot/proj2@all"
294 Import all changes from both named depot paths into a single
295 repository. Only files below these directories are included. There
296 is not a subdirectory in Git for each "proj1" and "proj2". You must
297 use the --destination option when specifying more than one depot
298 path. The revision specifier must be specified identically on each
299 depot path. If there are files in the depot paths with the same
300 name, the path with the most recently updated version of the file
301 is the one that appears in Git.
302 See p4 help revisions for the full syntax of p4 revision specifiers.
304
306 The p4 client specification is maintained with the p4 client command
307 and contains among other fields, a View that specifies how the depot is
308 mapped into the client repository. The clone and sync commands can
309 consult the client spec when given the --use-client-spec option or when
310 the useClientSpec variable is true. After git p4 clone, the
311 useClientSpec variable is automatically set in the repository
312 configuration file. This allows future git p4 submit commands to work
313 properly; the submit command looks only at the variable and does not
314 have a command-line option.
315 The full syntax for a p4 view is documented in p4 help views. git p4
317 knows only a subset of the view syntax. It understands multi-line
318 mappings, overlays with +, exclusions with - and double-quotes around
319 whitespace. Of the possible wildcards, git p4 only handles ..., and
320 only when it is at the end of the path. git p4 will complain if it
321 encounters an unhandled wildcard.
322 Bugs in the implementation of overlap mappings exist. If multiple depot
324 paths map through overlays to the same location in the repository, git
325 p4 can choose the wrong one. This is hard to solve without dedicating a
326 client spec just for git p4.
327 The name of the client can be given to git p4 in multiple ways. The
329 variable git-p4.client takes precedence if it exists. Otherwise, normal
330 p4 mechanisms of determining the client are used: environment variable
331 P4CLIENT, a file referenced by P4CONFIG, or the local host name.
332
334 P4 does not have the same concept of a branch as Git. Instead, p4
335 organizes its content as a directory tree, where by convention
336 different logical branches are in different locations in the tree. The
337 p4 branch command is used to maintain mappings between different areas
338 in the tree, and indicate related content. git p4 can use these
339 mappings to determine branch relationships.
340 If you have a repository where all the branches of interest exist as
342 subdirectories of a single depot path, you can use --detect-branches
343 when cloning or syncing to have git p4 automatically find
344 subdirectories in p4, and to generate these as branches in Git.
345 For example, if the P4 repository structure is:
347 //depot/main/...
349 //depot/branch1/...
350 And "p4 branch -o branch1" shows a View line that looks like:
353 //depot/main/... //depot/branch1/...
355 Then this git p4 clone command:
358 git p4 clone --detect-branches //depot@all
360 produces a separate branch in refs/remotes/p4/ for //depot/main, called
363 master, and one for //depot/branch1 called depot/branch1.
364 However, it is not necessary to create branches in p4 to be able to use
366 them like branches. Because it is difficult to infer branch
367 relationships automatically, a Git configuration setting
368 git-p4.branchList can be used to explicitly identify branch
369 relationships. It is a list of "source:destination" pairs, like a
370 simple p4 branch specification, where the "source" and "destination"
371 are the path elements in the p4 repository. The example above relied on
372 the presence of the p4 branch. Without p4 branches, the same result
373 will occur with:
374 git init depot
376 cd depot
377 git config git-p4.branchList main:branch1
378 git p4 clone --detect-branches //depot@all .
379
382 The fast-import mechanism used by git p4 creates one pack file for each
383 invocation of git p4 sync. Normally, Git garbage compression (git-
384 gc(1)) automatically compresses these to fewer pack files, but explicit
385 invocation of git repack -adf may improve performance.
386
388 The following config settings can be used to modify git p4 behavior.
389 They all are in the git-p4 section.
390 General variables
392 git-p4.user
393 User specified as an option to all p4 commands, with -u <user>. The
394 environment variable P4USER can be used instead.
395 git-p4.password
397 Password specified as an option to all p4 commands, with -P
398 <password>. The environment variable P4PASS can be used instead.
399 git-p4.port
401 Port specified as an option to all p4 commands, with -p <port>. The
402 environment variable P4PORT can be used instead.
403 git-p4.host
405 Host specified as an option to all p4 commands, with -h <host>. The
406 environment variable P4HOST can be used instead.
407 git-p4.client
409 Client specified as an option to all p4 commands, with -c <client>,
410 including the client spec.
411 Clone and sync variables
413 git-p4.syncFromOrigin
414 Because importing commits from other Git repositories is much
415 faster than importing them from p4, a mechanism exists to find p4
416 changes first in Git remotes. If branches exist under
417 refs/remote/origin/p4, those will be fetched and used when syncing
418 from p4. This variable can be set to false to disable this
419 behavior.
420 git-p4.branchUser
422 One phase in branch detection involves looking at p4 branches to
423 find new ones to import. By default, all branches are inspected.
424 This option limits the search to just those owned by the single
425 user named in the variable.
426 git-p4.branchList
428 List of branches to be imported when branch detection is enabled.
429 Each entry should be a pair of branch names separated by a colon
430 (:). This example declares that both branchA and branchB were
431 created from main:
432 git config git-p4.branchList main:branchA
434 git config --add git-p4.branchList main:branchB
435 git-p4.ignoredP4Labels
438 List of p4 labels to ignore. This is built automatically as
439 unimportable labels are discovered.
440 git-p4.importLabels
442 Import p4 labels into git, as per --import-labels.
443 git-p4.labelImportRegexp
445 Only p4 labels matching this regular expression will be imported.
446 The default value is [a-zA-Z0-9_\-.]+$.
447 git-p4.useClientSpec
449 Specify that the p4 client spec should be used to identify p4 depot
450 paths of interest. This is equivalent to specifying the option
451 --use-client-spec. See the "CLIENT SPEC" section above. This
452 variable is a boolean, not the name of a p4 client.
453 Submit variables
455 git-p4.detectRenames
456 Detect renames. See git-diff(1). This can be true, false, or a
457 score as expected by git diff -M.
458 git-p4.detectCopies
460 Detect copies. See git-diff(1). This can be true, false, or a score
461 as expected by git diff -C.
462 git-p4.detectCopiesHarder
464 Detect copies harder. See git-diff(1). A boolean.
465 git-p4.preserveUser
467 On submit, re-author changes to reflect the Git author, regardless
468 of who invokes git p4 submit.
469 git-p4.allowMissingP4Users
471 When preserveUser is true, git p4 normally dies if it cannot find
472 an author in the p4 user map. This setting submits the change
473 regardless.
474 git-p4.skipSubmitEdit
476 The submit process invokes the editor before each p4 change is
477 submitted. If this setting is true, though, the editing step is
478 skipped.
479 git-p4.skipSubmitEditCheck
481 After editing the p4 change message, git p4 makes sure that the
482 description really was changed by looking at the file modification
483 time. This option disables that test.
484 git-p4.allowSubmit
486 By default, any branch can be used as the source for a git p4
487 submit operation. This configuration variable, if set, permits only
488 the named branches to be used as submit sources. Branch names must
489 be the short names (no "refs/heads/"), and should be separated by
490 commas (","), with no spaces.
491 git-p4.skipUserNameCheck
493 If the user running git p4 submit does not exist in the p4 user
494 map, git p4 exits. This option can be used to force submission
495 regardless.
496 git-p4.attemptRCSCleanup
498 If enabled, git p4 submit will attempt to cleanup RCS keywords
499 ($Header$, etc). These would otherwise cause merge conflicts and
500 prevent the submit going ahead. This option should be considered
501 experimental at present.
502 git-p4.exportLabels
504 Export Git tags to p4 labels, as per --export-labels.
505 git-p4.labelExportRegexp
507 Only p4 labels matching this regular expression will be exported.
508 The default value is [a-zA-Z0-9_\-.]+$.
509 git-p4.conflict
511 Specify submit behavior when a conflict with p4 is found, as per
512 --conflict. The default behavior is ask.
513
515 · Changesets from p4 are imported using Git fast-import.
516 · Cloning or syncing does not require a p4 client; file contents are
518 collected using p4 print.
519 · Submitting requires a p4 client, which is not in the same location
521 as the Git repository. Patches are applied, one at a time, to this
522 p4 client and submitted from there.
523 · Each commit imported by git p4 has a line at the end of the log
525 message indicating the p4 depot location and change number. This
526 line is used by later git p4 sync operations to know which p4
527 changes are new.
528Git 1.8.3.1 11/19/2018 GIT-P4(1)