views:

349

answers:

3

I know this has come up before, but there was little in the way of day to day personal experiences in the posts I saw. Only a couple of responses. I'd love to hear from people that use git-p4, or have used git "under the covers" in a Perforce repo, or preferably both.
And for those people who just use git underneath another version control, I'd love to hear how you deal with notifying the main version control of changes. Specifically, with git/perforce, when you're done and ready to commit the changes to the perforce server, how do you deal with telling perforce what changes there's been?
I've looked into post-commit hooks with git, but I'd love to hear any other ideas.

+5  A: 

I used git-p4 at work. It's a bidirectional bridge so if you want to use git and then commit your local commits back into p4, it's a nice way to go. However, our office policy had a culture of a small number of massive commits rather than many small ones so I had to rebase all the changes into a single patch before submitting back into p4. I would have liked to maintain the fine grained local history but commit back in a single shot but never could manage.


Apropos change notification. git-p4 creates patches for every checkin since your last and submits them as separate changesets. This sort of mirrors the history of the main branch you're working on in your git repository.

Noufal Ibrahim
+1. How about a repo R1 dedicated to fine-grained local history (where you work), pushed to your repo managed by P4 (RP4), and where you can do a rebase -i *there* (preserving the small commits)?. When RP4 is updated with new data from Perforce, R1 could fetch from RP4, and rebase the remote/branch on top of its own detailed branch. Just a though on top of my head. May be that would trigger too much conflicts to be practical.
VonC
It sounds workable but quite complicated. Are you sure you want git *that* bad?
Noufal Ibrahim
@Noufal Ibrahim: only if you want to preserve two sets of the same history, since cloning repo is such easy to do with Git. But this is probably overkill, and just intended as a quick mental exercise ;)
VonC
+1  A: 

I use git with TFS and have chosen to go with Option 2: slide the .git directory in and have TFS ignore it. I do this for the same reason that @Noufal does, we have a culture here of "one big commit" vs. the tens of tiny commits I do in Git. Since I'm only committing to TFS once or twice a day, it's not worth it for me to mess around with post-commit hooks or rebases or anything else.

kubi
A: 

I guess it really depends on the layout of your perforce repository - if you're working on a relatively small section of it, then I'd probably just go for dropping the .git directory straight in. It's the least path of resistance by far and I have used it successfully on smaller projects.

That said, I have struggled with this approach on larger repositories, probably as much to do with the workflow where I work as the management overhead of it all. I've yet to have a look at git-p4, but it's something I'm interested in investigating further.

cristobalito