git-p4: introduce asciidoc documentation
Add proper documentation for git-p4. Delete the old .txt documentation from contrib/fast-import. Cc: Frans Klaver <fransklaver@gmail.com> Cc: Luke Diamand <luke@diamand.org> Signed-off-by: Pete Wyckoff <pw@padd.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
Pete Wyckoff committed
Dec 24, 2011 at 21:07 UTC
6679c34c47be19ba8e9ea72129dfe768a49c5ab4
2 files changed
+455
-302
Documentation/git-p4.txt
new
+455
@@ -0,0 +1,455 @@
1
+git-p4(1)
2
+=========
3
+
4
+NAME
5
+----
6
+git-p4 - Import from and submit to Perforce repositories
7
+
8
+
9
+SYNOPSIS
10
+--------
11
+[verse]
12
+'git p4 clone' [<sync options>] [<clone options>] <p4 depot path>...
13
+'git p4 sync' [<sync options>] [<p4 depot path>...]
14
+'git p4 rebase'
15
+'git p4 submit' [<submit options>] [<master branch name>]
16
+
17
+
18
+DESCRIPTION
19
+-----------
20
+This command provides a way to interact with p4 repositories
21
+using git.
22
+
23
+Create a new git repository from an existing p4 repository using
24
+'git p4 clone', giving it one or more p4 depot paths. Incorporate
25
+new commits from p4 changes with 'git p4 sync'. The 'sync' command
26
+is also used to include new branches from other p4 depot paths.
27
+Submit git changes back to p4 using 'git p4 submit'. The command
28
+'git p4 rebase' does a sync plus rebases the current branch onto
29
+the updated p4 remote branch.
30
+
31
+
32
+EXAMPLE
33
+-------
34
+* Create an alias for 'git p4', using the full path to the 'git-p4'
35
+ script if needed:
36
++
37
+------------
38
+$ git config --global alias.p4 '!git-p4'
39
+------------
40
+
41
+* Clone a repository:
42
++
43
+------------
44
+$ git p4 clone //depot/path/project
45
+------------
46
+
47
+* Do some work in the newly created git repository:
48
++
49
+------------
50
+$ cd project
51
+$ vi foo.h
52
+$ git commit -a -m "edited foo.h"
53
+------------
54
+
55
+* Update the git repository with recent changes from p4, rebasing your
56
+ work on top:
57
++
58
+------------
59
+$ git p4 rebase
60
+------------
61
+
62
+* Submit your commits back to p4:
63
++
64
+------------
65
+$ git p4 submit
66
+------------
67
+
68
+
69
+COMMANDS
70
+--------
71
+
72
+Clone
73
+~~~~~
74
+Generally, 'git p4 clone' is used to create a new git directory
75
+from an existing p4 repository:
76
+------------
77
+$ git p4 clone //depot/path/project
78
+------------
79
+This:
80
+
81
+1. Creates an empty git repository in a subdirectory called 'project'.
82
++
83
+2. Imports the full contents of the head revision from the given p4
84
+depot path into a single commit in the git branch 'refs/remotes/p4/master'.
85
++
86
+3. Creates a local branch, 'master' from this remote and checks it out.
87
+
88
+To reproduce the entire p4 history in git, use the '@all' modifier on
89
+the depot path:
90
+------------
91
+$ git p4 clone //depot/path/project@all
92
+------------
93
+
94
+
95
+Sync
96
+~~~~
97
+As development continues in the p4 repository, those changes can
98
+be included in the git repository using:
99
+------------
100
+$ git p4 sync
101
+------------
102
+This command finds new changes in p4 and imports them as git commits.
103
+
104
+P4 repositories can be added to an existing git repository using
105
+'git p4 sync' too:
106
+------------
107
+$ mkdir repo-git
108
+$ cd repo-git
109
+$ git init
110
+$ git p4 sync //path/in/your/perforce/depot
111
+------------
112
+This imports the specified depot into
113
+'refs/remotes/p4/master' in an existing git repository. The
114
+'--branch' option can be used to specify a different branch to
115
+be used for the p4 content.
116
+
117
+If a git repository includes branches 'refs/remotes/origin/p4', these
118
+will be fetched and consulted first during a 'git p4 sync'. Since
119
+importing directly from p4 is considerably slower than pulling changes
120
+from a git remote, this can be useful in a multi-developer environment.
121
+
122
+
123
+Rebase
124
+~~~~~~
125
+A common working pattern is to fetch the latest changes from the p4 depot
126
+and merge them with local uncommitted changes. Often, the p4 repository
127
+is the ultimate location for all code, thus a rebase workflow makes
128
+sense. This command does 'git p4 sync' followed by 'git rebase' to move
129
+local commits on top of updated p4 changes.
130
+------------
131
+$ git p4 rebase
132
+------------
133
+
134
+
135
+Submit
136
+~~~~~~
137
+Submitting changes from a git repository back to the p4 repository
138
+requires a separate p4 client workspace. This should be specified
139
+using the 'P4CLIENT' environment variable or the git configuration
140
+variable 'git-p4.client'. The p4 client must exist, but the client root
141
+will be created and populated if it does not already exist.
142
+
143
+To submit all changes that are in the current git branch but not in
144
+the 'p4/master' branch, use:
145
+------------
146
+$ git p4 submit
147
+------------
148
+
149
+To specify a branch other than the current one, use:
150
+------------
151
+$ git p4 submit topicbranch
152
+------------
153
+
154
+The upstream reference is generally 'refs/remotes/p4/master', but can
155
+be overridden using the '--origin=' command-line option.
156
+
157
+The p4 changes will be created as the user invoking 'git p4 submit'. The
158
+'--preserve-user' option will cause ownership to be modified
159
+according to the author of the git commit. This option requires admin
160
+privileges in p4, which can be granted using 'p4 protect'.
161
+
162
+
163
+OPTIONS
164
+-------
165
+
166
+General options
167
+~~~~~~~~~~~~~~~
168
+All commands except clone accept this option.
169
+
170
+--git-dir <dir>::
171
+ Set the 'GIT_DIR' environment variable. See linkgit:git[1].
172
+
173
+Sync options
174
+~~~~~~~~~~~~
175
+These options can be used in the initial 'clone' as well as in
176
+subsequent 'sync' operations.
177
+
178
+--branch <branch>::
179
+ Import changes into given branch. If the branch starts with
180
+ 'refs/', it will be used as is, otherwise the path 'refs/heads/'
181
+ will be prepended. The default branch is 'master'.
182
+
183
+--detect-branches::
184
+ Use the branch detection algorithm to find new paths in p4. It is
185
+ documented below in "BRANCH DETECTION".
186
+
187
+--changesfile <file>::
188
+ Import exactly the p4 change numbers listed in 'file', one per
189
+ line. Normally, 'git p4' inspects the current p4 repository
190
+ state and detects the changes it should import.
191
+
192
+--silent::
193
+ Do not print any progress information.
194
+
195
+--verbose::
196
+ Provide more progress information.
197
+
198
+--detect-labels::
199
+ Query p4 for labels associated with the depot paths, and add
200
+ them as tags in git.
201
+
202
+--import-local::
203
+ By default, p4 branches are stored in 'refs/remotes/p4/',
204
+ where they will be treated as remote-tracking branches by
205
+ linkgit:git-branch[1] and other commands. This option instead
206
+ puts p4 branches in 'refs/heads/p4/'.
207
+
208
+--max-changes <n>::
209
+ Limit the number of imported changes to 'n'. Useful to
210
+ limit the amount of history when using the '@all' p4 revision
211
+ specifier.
212
+
213
+--keep-path::
214
+ The mapping of file names from the p4 depot path to git, by
215
+ default, involves removing the entire depot path. With this
216
+ option, the full p4 depot path is retained in git. For example,
217
+ path '//depot/main/foo/bar.c', when imported from
218
+ '//depot/main/', becomes 'foo/bar.c'. With '--keep-path', the
219
+ git path is instead 'depot/main/foo/bar.c'.
220
+
221
+--use-client-spec::
222
+ Use a client spec to find the list of interesting files in p4.
223
+ The client spec is discovered using 'p4 client -o' which checks
224
+ the 'P4CLIENT' environment variable and returns a mapping of
225
+ depot files to workspace files.
226
+
227
+Clone options
228
+~~~~~~~~~~~~~
229
+These options can be used in an initial 'clone', along with the 'sync'
230
+options described above.
231
+
232
+--destination <directory>::
233
+ Where to create the git repository. If not provided, the last
234
+ component in the p4 depot path is used to create a new
235
+ directory.
236
+
237
+--bare::
238
+ Perform a bare clone. See linkgit:git-clone[1].
239
+
240
+-/ <path>::
241
+ Exclude selected depot paths when cloning.
242
+
243
+Submit options
244
+~~~~~~~~~~~~~~
245
+These options can be used to modify 'git p4 submit' behavior.
246
+
247
+--verbose::
248
+ Provide more progress information.
249
+
250
+--origin <commit>::
251
+ Upstream location from which commits are identified to submit to
252
+ p4. By default, this is the most recent p4 commit reachable
253
+ from 'HEAD'.
254
+
255
+-M[<n>]::
256
+ Detect renames. See linkgit:git-diff[1]. Renames will be
257
+ represented in p4 using explicit 'move' operations.
258
+
259
+--preserve-user::
260
+ Re-author p4 changes before submitting to p4. This option
261
+ requires p4 admin privileges.
262
+
263
+
264
+DEPOT PATH SYNTAX
265
+-----------------
266
+The p4 depot path argument to 'git p4 sync' and 'git p4 clone' can
267
+be one or more space-separated p4 depot paths, with an optional
268
+p4 revision specifier on the end:
269
+
270
+"//depot/my/project"::
271
+ Import one commit with all files in the '#head' change under that tree.
272
+
273
+"//depot/my/project@all"::
274
+ Import one commit for each change in the history of that depot path.
275
+
276
+"//depot/my/project@1,6"::
277
+ Import only changes 1 through 6.
278
+
279
+"//depot/proj1 //depot/proj2@all"::
280
+ Import all changes from both named depot paths.
281
+
282
+See 'p4 help revisions' for the full syntax of p4 revision specifiers.
283
+
284
+
285
+BRANCH DETECTION
286
+----------------
287
+P4 does not have the same concept of a branch as git. Instead,
288
+p4 organizes its content as a directory tree, where by convention
289
+different logical branches are in different locations in the tree.
290
+The 'p4 branch' command is used to maintain mappings between
291
+different areas in the tree, and indicate related content. 'git p4'
292
+can use these mappings to determine branch relationships.
293
+
294
+If you have a repository where all the branches of interest exist as
295
+subdirectories of a single depot path, you can use '--detect-branches'
296
+when cloning or syncing to have 'git p4' automatically find
297
+subdirectories in p4, and to generate these as branches in git.
298
+
299
+For example, if the P4 repository structure is:
300
+----
301
+//depot/main/...
302
+//depot/branch1/...
303
+----
304
+
305
+And "p4 branch -o branch1" shows a View line that looks like:
306
+----
307
+//depot/main/... //depot/branch1/...
308
+----
309
+
310
+Then this 'git p4 clone' command:
311
+----
312
+git p4 clone --detect-branches //depot@all
313
+----
314
+produces a separate branch in 'refs/remotes/p4/' for //depot/main,
315
+called 'master', and one for //depot/branch1 called 'depot/branch1'.
316
+
317
+However, it is not necessary to create branches in p4 to be able to use
318
+them like branches. Because it is difficult to infer branch
319
+relationships automatically, a git configuration setting
320
+'git-p4.branchList' can be used to explicitly identify branch
321
+relationships. It is a list of "source:destination" pairs, like a
322
+simple p4 branch specification, where the "source" and "destination" are
323
+the path elements in the p4 repository. The example above relied on the
324
+presence of the p4 branch. Without p4 branches, the same result will
325
+occur with:
326
+----
327
+git config git-p4.branchList main:branch1
328
+git p4 clone --detect-branches //depot@all
329
+----
330
+
331
+
332
+PERFORMANCE
333
+-----------
334
+The fast-import mechanism used by 'git p4' creates one pack file for
335
+each invocation of 'git p4 sync'. Normally, git garbage compression
336
+(linkgit:git-gc[1]) automatically compresses these to fewer pack files,
337
+but explicit invocation of 'git repack -adf' may improve performance.
338
+
339
+
340
+CONFIGURATION VARIABLES
341
+-----------------------
342
+The following config settings can be used to modify 'git p4' behavior.
343
+They all are in the 'git-p4' section.
344
+
345
+General variables
346
+~~~~~~~~~~~~~~~~~
347
+git-p4.user::
348
+ User specified as an option to all p4 commands, with '-u <user>'.
349
+ The environment variable 'P4USER' can be used instead.
350
+
351
+git-p4.password::
352
+ Password specified as an option to all p4 commands, with
353
+ '-P <password>'.
354
+ The environment variable 'P4PASS' can be used instead.
355
+
356
+git-p4.port::
357
+ Port specified as an option to all p4 commands, with
358
+ '-p <port>'.
359
+ The environment variable 'P4PORT' can be used instead.
360
+
361
+git-p4.host::
362
+ Host specified as an option to all p4 commands, with
363
+ '-h <host>'.
364
+ The environment variable 'P4HOST' can be used instead.
365
+
366
+git-p4.client::
367
+ Client specified as an option to all p4 commands, with
368
+ '-c <client>'. This can also be used as a way to find
369
+ the client spec for the 'useClientSpec' option.
370
+ The environment variable 'P4CLIENT' can be used instead.
371
+
372
+Clone and sync variables
373
+~~~~~~~~~~~~~~~~~~~~~~~~
374
+git-p4.syncFromOrigin::
375
+ Because importing commits from other git repositories is much faster
376
+ than importing them from p4, a mechanism exists to find p4 changes
377
+ first in git remotes. If branches exist under 'refs/remote/origin/p4',
378
+ those will be fetched and used when syncing from p4. This
379
+ variable can be set to 'false' to disable this behavior.
380
+
381
+git-p4.branchUser::
382
+ One phase in branch detection involves looking at p4 branches
383
+ to find new ones to import. By default, all branches are
384
+ inspected. This option limits the search to just those owned
385
+ by the single user named in the variable.
386
+
387
+git-p4.branchList::
388
+ List of branches to be imported when branch detection is
389
+ enabled. Each entry should be a pair of branch names separated
390
+ by a colon (:). This example declares that both branchA and
391
+ branchB were created from main:
392
+-------------
393
+git config git-p4.branchList main:branchA
394
+git config --add git-p4.branchList main:branchB
395
+-------------
396
+
397
+git-p4.useClientSpec::
398
+ Specify that the p4 client spec to be used to identify p4 depot
399
+ paths of interest. This is equivalent to specifying the option
400
+ '--use-client-spec'. The variable 'git-p4.client' can be used
401
+ to specify the name of the client.
402
+
403
+Submit variables
404
+~~~~~~~~~~~~~~~~
405
+git-p4.detectRenames::
406
+ Detect renames. See linkgit:git-diff[1].
407
+
408
+git-p4.detectCopies::
409
+ Detect copies. See linkgit:git-diff[1].
410
+
411
+git-p4.detectCopiesHarder::
412
+ Detect copies harder. See linkgit:git-diff[1].
413
+
414
+git-p4.preserveUser::
415
+ On submit, re-author changes to reflect the git author,
416
+ regardless of who invokes 'git p4 submit'.
417
+
418
+git-p4.allowMissingP4Users::
419
+ When 'preserveUser' is true, 'git p4' normally dies if it
420
+ cannot find an author in the p4 user map. This setting
421
+ submits the change regardless.
422
+
423
+git-p4.skipSubmitEdit::
424
+ The submit process invokes the editor before each p4 change
425
+ is submitted. If this setting is true, though, the editing
426
+ step is skipped.
427
+
428
+git-p4.skipSubmitEditCheck::
429
+ After editing the p4 change message, 'git p4' makes sure that
430
+ the description really was changed by looking at the file
431
+ modification time. This option disables that test.
432
+
433
+git-p4.allowSubmit::
434
+ By default, any branch can be used as the source for a 'git p4
435
+ submit' operation. This configuration variable, if set, permits only
436
+ the named branches to be used as submit sources.
437
+
438
+git-p4.skipUserNameCheck::
439
+ If the user running 'git p4 submit' does not exist in the p4
440
+ user map, 'git p4' exits. This option can be used to force
441
+ submission regardless.
442
+
443
+
444
+IMPLEMENTATION DETAILS
445
+----------------------
446
+* Changesets from p4 are imported using git fast-import.
447
+* Cloning or syncing does not require a p4 client; file contents are
448
+ collected using 'p4 print'.
449
+* Submitting requires a p4 client, which is not in the same location
450
+ as the git repository. Patches are applied, one at a time, to
451
+ this p4 client and submitted from there.
452
+* Each commit imported by 'git p4' has a line at the end of the log
453
+ message indicating the p4 depot location and change number. This
454
+ line is used by later 'git p4 sync' operations to know which p4
455
+ changes are new.
contrib/fast-import/git-p4.txt
deleted
-302
@@ -1,302 +0,0 @@
1
-git-p4 - Perforce <-> Git converter using git-fast-import
2
-
3
-Usage
4
-=====
5
-
6
-git-p4 can be used in two different ways:
7
-
8
-1) To import changes from Perforce to a Git repository, using "git-p4 sync".
9
-
10
-2) To submit changes from Git back to Perforce, using "git-p4 submit".
11
-
12
-Importing
13
-=========
14
-
15
-Simply start with
16
-
17
- git-p4 clone //depot/path/project
18
-
19
-or
20
-
21
- git-p4 clone //depot/path/project myproject
22
-
23
-This will:
24
-
25
-1) Create an empty git repository in a subdirectory called "project" (or
26
-"myproject" with the second command)
27
-
28
-2) Import the head revision from the given Perforce path into a git branch
29
-called "p4" (remotes/p4 actually)
30
-
31
-3) Create a master branch based on it and check it out.
32
-
33
-If you want the entire history (not just the head revision) then you can simply
34
-append a "@all" to the depot path:
35
-
36
- git-p4 clone //depot/project/main@all myproject
37
-
38
-
39
-
40
-If you want more control you can also use the git-p4 sync command directly:
41
-
42
- mkdir repo-git
43
- cd repo-git
44
- git init
45
- git-p4 sync //path/in/your/perforce/depot
46
-
47
-This will import the current head revision of the specified depot path into a
48
-"remotes/p4/master" branch of your git repository. You can use the
49
---branch=mybranch option to import into a different branch.
50
-
51
-If you want to import the entire history of a given depot path simply use:
52
-
53
- git-p4 sync //path/in/depot@all
54
-
55
-
56
-Note:
57
-
58
-To achieve optimal compression you may want to run 'git repack -a -d -f' after
59
-a big import. This may take a while.
60
-
61
-Incremental Imports
62
-===================
63
-
64
-After an initial import you can continue to synchronize your git repository
65
-with newer changes from the Perforce depot by just calling
66
-
67
- git-p4 sync
68
-
69
-in your git repository. By default the "remotes/p4/master" branch is updated.
70
-
71
-Advanced Setup
72
-==============
73
-
74
-Suppose you have a periodically updated git repository somewhere, containing a
75
-complete import of a Perforce project. This repository can be cloned and used
76
-with git-p4. When updating the cloned repository with the "sync" command,
77
-git-p4 will try to fetch changes from the original repository first. The git
78
-protocol used with this is usually faster than importing from Perforce
79
-directly.
80
-
81
-This behaviour can be disabled by setting the "git-p4.syncFromOrigin" git
82
-configuration variable to "false".
83
-
84
-Updating
85
-========
86
-
87
-A common working pattern is to fetch the latest changes from the Perforce depot
88
-and merge them with local uncommitted changes. The recommended way is to use
89
-git's rebase mechanism to preserve linear history. git-p4 provides a convenient
90
-
91
- git-p4 rebase
92
-
93
-command that calls git-p4 sync followed by git rebase to rebase the current
94
-working branch.
95
-
96
-Submitting
97
-==========
98
-
99
-git-p4 has support for submitting changes from a git repository back to the
100
-Perforce depot. This requires a Perforce checkout separate from your git
101
-repository. To submit all changes that are in the current git branch but not in
102
-the "p4" branch (or "origin" if "p4" doesn't exist) simply call
103
-
104
- git-p4 submit
105
-
106
-in your git repository. If you want to submit changes in a specific branch that
107
-is not your current git branch you can also pass that as an argument:
108
-
109
- git-p4 submit mytopicbranch
110
-
111
-You can override the reference branch with the --origin=mysourcebranch option.
112
-
113
-The Perforce changelists will be created with the user who ran git-p4. If you
114
-use --preserve-user then git-p4 will attempt to create Perforce changelists
115
-with the Perforce user corresponding to the git commit author. You need to
116
-have sufficient permissions within Perforce, and the git users need to have
117
-Perforce accounts. Permissions can be granted using 'p4 protect'.
118
-
119
-If a submit fails you may have to "p4 resolve" and submit manually. You can
120
-continue importing the remaining changes with
121
-
122
- git-p4 submit --continue
123
-
124
-Example
125
-=======
126
-
127
-# Clone a repository
128
- git-p4 clone //depot/path/project
129
-# Enter the newly cloned directory
130
- cd project
131
-# Do some work...
132
- vi foo.h
133
-# ... and commit locally to gi
134
- git commit foo.h
135
-# In the meantime somebody submitted changes to the Perforce depot. Rebase your latest
136
-# changes against the latest changes in Perforce:
137
- git-p4 rebase
138
-# Submit your locally committed changes back to Perforce
139
- git-p4 submit
140
-# ... and synchronize with Perforce
141
- git-p4 rebase
142
-
143
-
144
-Configuration parameters
145
-========================
146
-
147
-git-p4.user ($P4USER)
148
-
149
-Allows you to specify the username to use to connect to the Perforce repository.
150
-
151
- git config [--global] git-p4.user public
152
-
153
-git-p4.password ($P4PASS)
154
-
155
-Allows you to specify the password to use to connect to the Perforce repository.
156
-Warning this password will be visible on the command-line invocation of the p4 binary.
157
-
158
- git config [--global] git-p4.password public1234
159
-
160
-git-p4.port ($P4PORT)
161
-
162
-Specify the port to be used to contact the Perforce server. As this will be passed
163
-directly to the p4 binary, it may be in the format host:port as well.
164
-
165
- git config [--global] git-p4.port codes.zimbra.com:2666
166
-
167
-git-p4.host ($P4HOST)
168
-
169
-Specify the host to contact for a Perforce repository.
170
-
171
- git config [--global] git-p4.host perforce.example.com
172
-
173
-git-p4.client ($P4CLIENT)
174
-
175
-Specify the client name to use
176
-
177
- git config [--global] git-p4.client public-view
178
-
179
-git-p4.allowSubmit
180
-
181
- git config [--global] git-p4.allowSubmit false
182
-
183
-git-p4.syncFromOrigin
184
-
185
-A useful setup may be that you have a periodically updated git repository
186
-somewhere that contains a complete import of a Perforce project. That git
187
-repository can be used to clone the working repository from and one would
188
-import from Perforce directly after cloning using git-p4. If the connection to
189
-the Perforce server is slow and the working repository hasn't been synced for a
190
-while it may be desirable to fetch changes from the origin git repository using
191
-the efficient git protocol. git-p4 supports this setup by calling "git fetch origin"
192
-by default if there is an origin branch. You can disable this using:
193
-
194
- git config [--global] git-p4.syncFromOrigin false
195
-
196
-git-p4.useclientspec
197
-
198
- git config [--global] git-p4.useclientspec false
199
-
200
-The P4CLIENT environment variable should be correctly set for p4 to be
201
-able to find the relevant client. This client spec will be used to
202
-both filter the files cloned by git and set the directory layout as
203
-specified in the client (this implies --keep-path style semantics).
204
-
205
-git-p4.skipSubmitEdit
206
-
207
- git config [--global] git-p4.skipSubmitEdit false
208
-
209
-Normally, git-p4 invokes an editor after each commit is applied so
210
-that you can make changes to the submit message. Setting this
211
-variable to true will skip the editing step, submitting the change as is.
212
-
213
-git-p4.skipSubmitEditCheck
214
-
215
- git config [--global] git-p4.skipSubmitEditCheck false
216
-
217
-After the editor is invoked, git-p4 normally makes sure you saved the
218
-change description, as an indication that you did indeed read it over
219
-and edit it. You can quit without saving to abort the submit (or skip
220
-this change and continue). Setting this variable to true will cause
221
-git-p4 not to check if you saved the change description. This variable
222
-only matters if git-p4.skipSubmitEdit has not been set to true.
223
-
224
-git-p4.preserveUser
225
-
226
- git config [--global] git-p4.preserveUser false
227
-
228
-If true, attempt to preserve user names by modifying the p4 changelists. See
229
-the "--preserve-user" submit option.
230
-
231
-git-p4.allowMissingPerforceUsers
232
-
233
- git config [--global] git-p4.allowMissingP4Users false
234
-
235
-If git-p4 is setting the perforce user for a commit (--preserve-user) then
236
-if there is no perforce user corresponding to the git author, git-p4 will
237
-stop. With allowMissingPerforceUsers set to true, git-p4 will use the
238
-current user (i.e. the behavior without --preserve-user) and carry on with
239
-the perforce commit.
240
-
241
-git-p4.skipUserNameCheck
242
-
243
- git config [--global] git-p4.skipUserNameCheck false
244
-
245
-When submitting, git-p4 checks that the git commits are authored by the current
246
-p4 user, and warns if they are not. This disables the check.
247
-
248
-git-p4.detectRenames
249
-
250
-Detect renames when submitting changes to Perforce server. Will enable -M git
251
-argument. Can be optionally set to a number representing the threshold
252
-percentage value of the rename detection.
253
-
254
- git config [--global] git-p4.detectRenames true
255
- git config [--global] git-p4.detectRenames 50
256
-
257
-git-p4.detectCopies
258
-
259
-Detect copies when submitting changes to Perforce server. Will enable -C git
260
-argument. Can be optionally set to a number representing the threshold
261
-percentage value of the copy detection.
262
-
263
- git config [--global] git-p4.detectCopies true
264
- git config [--global] git-p4.detectCopies 80
265
-
266
-git-p4.detectCopiesHarder
267
-
268
-Detect copies even between files that did not change when submitting changes to
269
-Perforce server. Will enable --find-copies-harder git argument.
270
-
271
- git config [--global] git-p4.detectCopies true
272
-
273
-git-p4.branchUser
274
-
275
-Only use branch specifications defined by the selected username.
276
-
277
- git config [--global] git-p4.branchUser username
278
-
279
-git-p4.branchList
280
-
281
-List of branches to be imported when branch detection is enabled.
282
-
283
- git config [--global] git-p4.branchList main:branchA
284
- git config [--global] --add git-p4.branchList main:branchB
285
-
286
-Implementation Details...
287
-=========================
288
-
289
-* Changesets from Perforce are imported using git fast-import.
290
-* The import does not require anything from the Perforce client view as it just uses
291
- "p4 print //depot/path/file#revision" to get the actual file contents.
292
-* Every imported changeset has a special [git-p4...] line at the
293
- end of the log message that gives information about the corresponding
294
- Perforce change number and is also used by git-p4 itself to find out
295
- where to continue importing when doing incremental imports.
296
- Basically when syncing it extracts the perforce change number of the
297
- latest commit in the "p4" branch and uses "p4 changes //depot/path/...@changenum,#head"
298
- to find out which changes need to be imported.
299
-* git-p4 submit uses "git rev-list" to pick the commits between the "p4" branch
300
- and the current branch.
301
- The commits themselves are applied using git diff/format-patch ... | git apply
302
-