Perforce for git users.

perforce.MD

Understanding Perforce (as a git user).

Commands

Git	Perforce Command Line	P4V	Notes
git pull	p4 sync	get latest revision
n/a	p4 update	?	Get latest revision without overwriting files that have been changed.
git checkout	p4 edit	checkout	You plan to change a file from the version control system
git commit	p4 submit	submit
git push	n/a	n/a	No perforce equivalent. There is no concept of a pure local submit in Perforce.
git status	p4 status	?
git stash	p4 shelve
git blame	p4 annotate

Terminology

Git	Perforce
Git	Perforce
Repository	Depot
Local Repository	Workspace

Sample workflow

1 - Get the files from the server

cd /Users/turtle/work
p4 sync

2 - Checkout the file you want to work on and modify it

p4 edit main/foo; 
echo cake >> main/foo

3 - Submit it to the server

p4 submit -d "A trivial edit"

Useful Commands

1. Revert all changes

 p4 revert //...

2. Restore workspace files to match the state of corresponding depot files.

p4 clean

Resources:

1. https://stackoverflow.com/questions/17267218/perforce-for-git-users

In git, you do not need to tell the system you are going to edit a file.

git checkout file.txt

reverts any changes that were made to the file back to the version in the current repo.

This is not equivalent to

p4 edit

Right @cplager, git checkout is all bound up with git's branching system, which (as far as I can tell) is nothing like anything in Perforce. The closest p4 edit equivalent (that I can think of) is after you have edited a file in your local repo/branch -- you need to git add it to the staging area before it can be committed. Notably, this is different from p4 add which is for adding whole new file to the filesystem.

p4 update surely that's equivalent to git fetch??

'p4 edit' is definitely an 'n/a', and it's linked to one of the massively distinguishing features of perforce.

Perforce has a concept of a global lock, which it turns out is critical for things like binary assets. If two artists are working on the same texture, how do you merge that? And since perforce lets everyone see the depot differently, it's quite common for people to not realize they're treading on someone else's work thru other means.

So p4 defaults to marking all files read-only so that you cant easily change something you didn't intend to (a common thing with art tools which will randomly rewrite config files or re-generate some source item).

With svn/git you run status and it goes off and checks files for changes.

With p4, you tell perforce first with p4 edit. In exchange, it unlocks the file(s) for you and associates them with your current/default changelist.

So, it's closer to "git stage", but then it's also not that, because it has nothing to do with changes already made...

But last and MOST importantly:

"p4 edit" interacts with files that are marked as requiring global locks, so that only one person can manipulate that file across a stream.

I think there are some misunderstandings of both perforce and git here. In some ways they're more alike than it seems.

Think of it like this:

When you just map a depot to a local workspace, that's like having a ".svn" folder - a local checkout of remote files.

But when you use the "local server", it's really more like having a ".git" folder where you have the ability to create all your own streams and branches and files and version numbers...

So p4 totally has a concept of push: http://ftp.perforce.com/perforce/r16.2/doc/manuals/cmdref/p4_push.html