So which is better, using git-p4 or just sliding a

Question

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.

Answer 1

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.

Answer 2

The way I do it is to have a master branch and feature branches in git, and then use git diff --name-only master on a feature branch to figure out what files I've changed for a particular feature. I then check those files out into a Perforce changelist and submit it.

...well, more or less... :) In practice, we use Code Collaborator for code reviews, so I check the files out sometime between starting work on the feature and submitting the files for code review (it doesn't really matter much when). I then check before the code review that I've got all the files I should have using the above git command. (Actually, because I'm paranoid, I now do a git clean -xdf in my source directory and do a Perforce "Reconcile Offline Work" to double-check what I'm about to submit. I then do a full rebuild of the whole project. Breaking the build is embarrassing, after all.) Once all the reviewing's done, I just submit the changelist as normal.

It's a bit of a faff, really, but it's not so bad now that I've got used to it - and it's a lot better than just using Perforce with massive commits, and effectively working without any sort of version control for days at a time :)

Answer 3

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.

Answer 4

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.