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.
views:
349answers:
3I 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.
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.
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.