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

Here's a crude solution. After you sync from p4, Do a git init in that directory, add all the files and commit them. Do your work completely ignoring git and then add and commit them back into p4.

This and some related things were discussion in this question.

Answer 2

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

Answer 3

I do the same thing at work with StarTeam and git. I'm not familiar with perforce syntax, but the concepts should match.

First of all, the initial git commit is always slow. After that, it might take 5-10 seconds to scan changed files for staging, but the commit should happen nearly instantaneously most of the time. For context, our code base has approximately 50,000 versioned files.

I keep master synced up with StarTeam, but don't do any development work directly in it. I do a git checkout master, then do a StarTeam update, then a git add and commit.

Then for my work, I make a new branch, do all my work in there, do another StarTeam update in master, and merge my feature branch back into master before committing to StarTeam. Thus, StarTeam check ins and outs are all done in master, and development is always done in other branches, which keeps the StarTeam updates clean.

This mixed approach has some other nice benefits, like being able to put partial work on hold for a while for code reviews, field issues, or whatever. I currently have 5 git branches in various states of use. It's also real nice for putting in temporary debugging code.

Answer 4

As you are using P4V anyway, I would recommend you to at least try the relatively new offline support option. It allows you to most of what you're asking for (except for using Git).

Answer 5

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.