September 14, 2013

Git for Perforce users

I have been playing around with Git. I’m a big fan of perforce. After using GIT, I’m a bigger fan of perforce.

Git thinks differently — It assumes that all developers don’t trust each other, and only a “core few” really have rights to the source tree. Each developer then works on their own dev branch. Git also thinks of the changelist — you “add files” to a change. Perforce thinks of the filesystem — You “add files” VIA the change. The difference between “to the change” and “Via the change” is very different. Here’s a quick mapping of perforce commands to their GIT equal.

p4 branch X “//depot/foo/… //depot/bar/…” –> Different concept. Perforce is using the branch as a map between one depot namespace and another. Git uses the branch as a changelist tracker. You can kind of map between them, but the differences can get you if you’re not careful.

Because GIT treats branches as trackers, to throw away a branch and reset to the fork’s master tracker named “foo” in this example ( most people use either “master” or “develop”, but I chose foo because you can call this tracker anything you like ):

git reset –hard upstream/foo —

git push origin +foo

( the + means force the push )

In Git, common branch names are “master” and “develop”. In perforce, there’s not really a concept of master, but rather, a depot namespace mapped to a client workspace. Git doesn’t map — your clone matches the source tree of the branch you’re working on, always. Again, I think perforce’s maps are better for developers, who often work on really small chunks of the tree, and don’t really need to clone an entire tree.