=====
git-p4 supports two main modes: Importing from Perforce to a Git repository is
-done using "git-p4 sync". Submitting changes from Git back to Perforce is
-done using "git-p4 submit".
+done using "git-p4 sync" or "git-p4 rebase". Submitting changes from Git back
+to Perforce is done using "git-p4 submit".
Importing
=========
-The procedure is simple:
+You can simply start with
+
+ git-p4 clone //depot/path/project
+
+or
+
+ git-p4 clone //depot/path/project myproject
+
+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 (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
+
+
+
+If you want more control you can also use the git-p4 sync command directly:
mkdir repo-git
cd repo-git
Support for Perforce integrations is still work in progress. Don't bother
trying it unless you want to hack on it :)
-
Incremental Imports
===================
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
========
After submitting you should sync your perforce import branch ("p4" or "origin")
from Perforce using git-p4's sync command.
+
+
+Example
+=======
+
+# Clone a repository
+ git-p4 clone //depot/path/project
+# Enter the newly cloned directory
+ cd project
+# Do some work...
+ vi foo.h
+# ... and commit locally to gi
+ git commit foo.h
+# In the meantime somebody submitted changes to the Perforce depot. Rebase your latest
+# changes against the latest changes in Perforce:
+ git-p4 rebase
+# Submit your locally committed changes back to Perforce
+ git-p4 submit
+# ... and synchronize with Perforce
+ git-p4 rebase
+
+
+Implementation Details...
+=========================
+
+* Changesets from Perforce are imported using git fast-import.
+* The import does not require anything from the Perforce client view as it just uses
+ "p4 print //depot/path/file#revision" to get the actual file contents.
+* Every imported changeset has a special [git-p4...] line at the
+ end of the log message that gives information about the corresponding
+ Perforce change number and is also used by git-p4 itself to find out
+ where to continue importing when doing incremental imports.
+ Basically when syncing it extracts the perforce change number of the
+ latest commit in the "p4" branch and uses "p4 changes //depot/path/...@changenum,#head"
+ to find out which changes need to be imported.
+* git-p4 submit uses "git rev-list" to pick the commits between the "p4" branch
+ and the current branch.
+ The commits themselves are applied using git diff-tree ... | patch -p1
+