So which is better, using git-p4 or just sliding a .git directory into the working directory and having perforce ignore it?

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 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 2

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.