How can I set up Git for local commits while using P4 for remote commits?

Question

Where I work uses a Perforce environment but we are not allowed to check in until our features are completed and ready to be tested. I need to be able to do local commits because at times I have had upwards of 50 files checked out for a week without any versioning on my changes.

Git fits my purpose, but I am not sure how to set it up to best integrate with the rest of my environment.

My goals are:

• When working on a feature I would like to be able to completely ignore Perforce and edit and commit as much as i please (in Git).
• Before submitting a feature, I need to be able to go into P4V or P4Win to diff the files and make sure everything is up to date, and after testing I would like all my changes to be in a single commit.

It seems like creating a git repository at the root directory of my local workspace would work, but I have some issues...

1. There are a massive amount of files in this repository and at least with the initial commit git is crawling.
2. I need to be able to easily update the git repository when I "get latest" from Perforce
3. I don't want to have to deal with checking out every file in Perforce before I edit it, nor do I want to have to do a Force Sync in Perforce because their are writable files that aren't checked out.

Can anyone give me some tips about this? I've been looking at submodules in git as a way to potentially reduce the size of the git repo as there are a lot of portions of the perforce repo that I don't need versioning on.

Answer 1

You should go with git-p4. This answer might be helpful as well.

Answer 2

I am currently using exactly this workflow and it's pretty great

For corporate reasons I can't use the git-p4 commands, but I've got a git repo living inside my client workspace directory. Our setup has configuration-code-only checked in to source control, with the rest of the dev setup stored in a ZIP. Thus I never reconcile on the workspace root anyway, which has the added bonus of not needing to explicitly ignore .git.

Addressing your points:

1. The initial commit can be expected to be...well, not the speediest. It's not cloning an existing repo, it's building one up from scratch.

2. Occasionally I'll save+commit what I'm working on,

   git checkout master && p4 sync && git add --all . && git commit -mupdate && git checkout feature-branch
   

   and then continue to hack. Merges tend to be much smoother in Git than in Perforce so usually you won't have to break focus because of conflicts. @p4mataway told me that they're working on merging better, though, so that'll be neat to see.

3. I turned on the 'allwrite' workspace option (don't keep unedited files read-only) and when I'm ready to check something in, I'll merge that branch down to master and then Reconcile in P4V. I'd do that from the command-line too but, corporate reasons again. Long story.

Git has been tremendously useful to me when dealing with features that involve multiple changes to the same file, as tends to happen with long-pending changes - typically database schema changes that require our application's database to be reset and we don't want to do that on the test servers right now because QA are in the middle of scenarios. The longer a changelist stays around, the more likely some unrelated work is to touch one of the same files, and being able to branch locally keeps the changes from getting stuck together. That feature alone is enough to make this whole setup entirely worthwhile.

Disclaimer - I don't intend to keep this Git repo around forever. Once some of the Corporate Reasons are resolved with an upcoming server upgrade I'll be able to use some very shiny Perforce features that our current environment doesn't support.