Removed unused variable, more cleanups
[gitweb.git] / contrib / fast-import / git-p4.txt
index ff0da9d0c8339ce0c6fadda2c1f5b423627d3f1f..ac8e6cff0bff9b34231037ea54c9e8fe696f0bd6 100644 (file)
@@ -20,9 +20,9 @@ or
 
 This will create an empty git repository in a subdirectory called "project" (or
 "myproject" with the second command), import the head revision from the
-specified perforce path into a git "p4" branch, create a master branch off it
-and check it out. If you want the entire history (not just the head revision) then
-you can simply append a "@all" to the depot path:
+specified perforce path into a git "p4" branch (remotes/p4 actually), create a
+master branch off it and check it out. If you want the entire history (not just
+the head revision) then you can simply append a "@all" to the depot path:
 
   git-p4 clone //depot/project/main@all myproject
 
@@ -63,6 +63,26 @@ It is recommended to run 'git repack -a -d -f' from time to time when using
 incremental imports to optimally combine the individual git packs that each
 incremental import creates through the use of git-fast-import.
 
+
+A useful setup may be that you have a periodically updated git repository
+somewhere that contains a complete import of a Perforce project. That git
+repository can be used to clone the working repository from and one would
+import from Perforce directly after cloning using git-p4. If the connection to
+the Perforce server is slow and the working repository hasn't been synced for a
+while it may be desirable to fetch changes from the origin git repository using
+the efficient git protocol. git-p4 supports this through
+
+  git-p4 sync --with-origin
+
+or
+
+  git-p4 rebase --with-origin
+
+In that case "git fetch origin" is called and if it turns out that the origin
+branch is newer than the git "p4" import branch then the latter is updated from
+the former and the direct import from Perforce is resumed, which will result in
+fewer changes to be imported using the slower perforce connection.
+
 Updating
 ========