{"thread":{"id":"26407","subject":"git-p4 - workflow suggestions","startedAt":"2011-02-04T00:23:26Z","lastAt":"2011-02-04T17:41:36Z","messageCount":3,"participants":["Kaizer H. Sogiawala","Tor Arvid Lund"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"160368","messageId":"AANLkTik3iFXZE6KSvSSgka3rJyCQbPXpUrTWRGyonfT=@mail.gmail.com","threadId":"26407","inReplyTo":null,"subject":"git-p4 - workflow suggestions","fromName":"Kaizer H. Sogiawala","fromEmail":"kaizers@gmail.com","sentAt":"2011-02-04T00:23:26Z","receivedAt":"2011-02-04T00:23:26Z","isPatch":false,"sender":{"key":"kaizers@gmail.com","avatar":null},"body":"Hi,\n\nWe are primarily a Perforce shop. I am looking for a git-p4 workflow\nthat will alllow a sub-team (2-20 developers) to use git as their\nprimary source control repository. This sub-team is tasked with\nrefactoring and will need heavy-duty branch/merge support. The\nmain/central source code repository (and branch) is in Perforce.\n\nI am looking at approaches that will allow me to \"git-p4 clone\" from\nPerforce (a branch in perforce, say trunk) into a bare/shared git\nrepository. This repository is then cloned by each developer of the\ngit-sub-team to perform regular development/push/pull/merge/rebase\nactivities.\n\nPeriodically, a gatekeeper would pull changes from Perforce to git and\npush changes from git to Perforce. Can this be done?\n\nSo far, I have looked at the:\n- git-p4 documentation\n- Version Control with Git book By: Jon Loeliger (particularly the\ngit-svn section)\n- Mailing list (particularly following thread answered by Tor Arvid Lund)\n- googl'n around this topic\n\nMost discussion is around how to use git-p4 as a sync mechanism for a\nsingle user. When I attempt to git-p4 clone (import) and then create a\nshared/bare repository out of it and emulating multiple user, the\ngit-p4 sync mechanism breaks down after couple of merges. The git-p4\nsync/rebase/submit will try to reapply duplicate changes and trip\npretty early in the cycle.\n\nIf you have a working model of making available a p4 branch for a\nsub-team using git-p4, I would really appreciate a writeup or blog.\nThanks in advance.\n\n-- \nKaizer\n"},{"id":"160387","messageId":"AANLkTik7Gv6vOgYNyuz-TCD6SAPV5G8f7RujEpfEYU3Q@mail.gmail.com","threadId":"26407","inReplyTo":"AANLkTik3iFXZE6KSvSSgka3rJyCQbPXpUrTWRGyonfT=@mail.gmail.com","subject":"Re: git-p4 - workflow suggestions","fromName":"Tor Arvid Lund","fromEmail":"torarvid@gmail.com","sentAt":"2011-02-04T10:26:49Z","receivedAt":"2011-02-04T10:26:49Z","isPatch":false,"sender":{"key":"torarvid@gmail.com","avatar":"https://avatars.githubusercontent.com/u/439758?v=4"},"body":"On Fri, Feb 4, 2011 at 1:23 AM, Kaizer H. Sogiawala <kaizers@gmail.com> wrote:\n> Hi,\n>\n> We are primarily a Perforce shop. I am looking for a git-p4 workflow\n> that will alllow a sub-team (2-20 developers) to use git as their\n> primary source control repository. This sub-team is tasked with\n> refactoring and will need heavy-duty branch/merge support. The\n> main/central source code repository (and branch) is in Perforce.\n>\n> I am looking at approaches that will allow me to \"git-p4 clone\" from\n> Perforce (a branch in perforce, say trunk) into a bare/shared git\n> repository. This repository is then cloned by each developer of the\n> git-sub-team to perform regular development/push/pull/merge/rebase\n> activities.\n\nHey! Yes, this should be possible - at least to some extent. What I\ndid personally, was to keep things as simple as possible, and decide\nearly on that I wouldn't hope to be able to do *everything* with\ngit-p4/perforce that I *could* do in git. [branch/merge tradeoff\ndetails will follow]\n\n> Periodically, a gatekeeper would pull changes from Perforce to git and\n> push changes from git to Perforce. Can this be done?\n\nI think I did kind of what you describe... I had one \"blessed\" git-p4\nrepo. That repo would be setup by:\n\ngit p4 clone --import-local //depot/path@all myproject\n\n(The \"--import-local\" makes sure that the p4 branch is placed in\nrefs/heads/ instead of refs/remotes. Better when the actual users\nclone the git repo later...)\n\nThen I made a simple script that would loop through all my git-p4\nprojects... basically just 'cd' into the dir and do 'git p4 sync'.\nThis script would be run by a cron job every <whatever> minutes so it\nwould always be reasonably up-to-date.\n\n> So far, I have looked at the:\n> - git-p4 documentation\n> - Version Control with Git book By: Jon Loeliger (particularly the\n> git-svn section)\n> - Mailing list (particularly following thread answered by Tor Arvid Lund)\n> - googl'n around this topic\n>\n> Most discussion is around how to use git-p4 as a sync mechanism for a\n> single user. When I attempt to git-p4 clone (import) and then create a\n> shared/bare repository out of it and emulating multiple user, the\n> git-p4 sync mechanism breaks down after couple of merges. The git-p4\n> sync/rebase/submit will try to reapply duplicate changes and trip\n> pretty early in the cycle.\n>\n> If you have a working model of making available a p4 branch for a\n> sub-team using git-p4, I would really appreciate a writeup or blog.\n> Thanks in advance.\n\nOk, so to make things practical, I made some simple 'rules' for myself:\n\n* The blessed git repo would be \"pull-only\" for the git users. That is\n- no one pushes to that repo. It reads from p4, and the users do 'git\nfetch/pull' from that. Nothing more, nothing less...\n\n* When preparing commits for upload to perforce, *always* rebase them\non top of the latest git-p4 tip.\n\nI never tried to do merges in git, and then try to turn that into\n'integrates' in perforce. So I always kept the perforce-things\n'linear' so that the communication between git and perforce should be\neasy. IOW I always did the \"official\" branching and integrate'ing\nusing the perforce client.\n\nWe did 'git p4 submit' directly from the users' git repos (which would\nbe synced by the blessed git repo, and from there to the other git\nusers). If you want another layer in-between [we use gerrit\ncode-review... You may have something else, or an integration manager\netc], you could push to another <some-project-manager-repo> and do all\ngit-p4 submits from there, I guess...\n\n\nOf course, these branch/merge limitations only apply to my git history\nat the point where I want to push to perforce. In all my daily work, I\ncreate topic branches, rebase, reorder commits... all of the git\ngoodness. I simply \"linearize\" things when I want to push...\n\n\nIn your use-case, if you are going to do work that will result in many\nperforce integrates, you may have a harder time with git-p4 than I\ndid, but it should be worth a try so that you can delight in daily git\nusage instead of cursing the awfulness that is perforce.\n\nAnd yes, git-p4 does rewrite every commit after you submit it. This is\nbecause of the quite simple design that was used to help git-p4 \"know\"\nwhat had been synced from perforce to git. Commit messages get the\nappended \"[git-p4: depot-paths = ... change = 12345]\" line. If git-p4\nhad been written today, this could have maybe been solved using\ngit-notes instead of rewriting commit msgs. I'm just saying... :)\n\nOtherwise, you will have to get around the fact that it rewrites\neverything. For me, I have used git rebase a *lot* :)\n\nGood luck!\n\n    -- Tor Arvid\n"},{"id":"160401","messageId":"AANLkTimF0AJLLAwVCY=yDqySrT8UunscUYopypei23UX@mail.gmail.com","threadId":"26407","inReplyTo":"AANLkTik7Gv6vOgYNyuz-TCD6SAPV5G8f7RujEpfEYU3Q@mail.gmail.com","subject":"Re: git-p4 - workflow suggestions","fromName":"Kaizer H. Sogiawala","fromEmail":"kaizers@gmail.com","sentAt":"2011-02-04T17:41:36Z","receivedAt":"2011-02-04T17:41:36Z","isPatch":false,"sender":{"key":"kaizers@gmail.com","avatar":null},"body":"Thanks a bunch Tor. It seems you are using a non-bare repo as the\n\"blessed\" repository and mitigating the risk or getting the workspace\nmessed up by always \"pulling\" changes that need to go in Perforce. I\nwill give it a try and post back.\n\nThanks for the post.\n\nOn Fri, Feb 4, 2011 at 2:26 AM, Tor Arvid Lund <torarvid@gmail.com> wrote:\n> On Fri, Feb 4, 2011 at 1:23 AM, Kaizer H. Sogiawala <kaizers@gmail.com> wrote:\n>> Hi,\n>>\n>> We are primarily a Perforce shop. I am looking for a git-p4 workflow\n>> that will alllow a sub-team (2-20 developers) to use git as their\n>> primary source control repository. This sub-team is tasked with\n>> refactoring and will need heavy-duty branch/merge support. The\n>> main/central source code repository (and branch) is in Perforce.\n>>\n>> I am looking at approaches that will allow me to \"git-p4 clone\" from\n>> Perforce (a branch in perforce, say trunk) into a bare/shared git\n>> repository. This repository is then cloned by each developer of the\n>> git-sub-team to perform regular development/push/pull/merge/rebase\n>> activities.\n>\n> Hey! Yes, this should be possible - at least to some extent. What I\n> did personally, was to keep things as simple as possible, and decide\n> early on that I wouldn't hope to be able to do *everything* with\n> git-p4/perforce that I *could* do in git. [branch/merge tradeoff\n> details will follow]\n>\n>> Periodically, a gatekeeper would pull changes from Perforce to git and\n>> push changes from git to Perforce. Can this be done?\n>\n> I think I did kind of what you describe... I had one \"blessed\" git-p4\n> repo. That repo would be setup by:\n>\n> git p4 clone --import-local //depot/path@all myproject\n>\n> (The \"--import-local\" makes sure that the p4 branch is placed in\n> refs/heads/ instead of refs/remotes. Better when the actual users\n> clone the git repo later...)\n>\n> Then I made a simple script that would loop through all my git-p4\n> projects... basically just 'cd' into the dir and do 'git p4 sync'.\n> This script would be run by a cron job every <whatever> minutes so it\n> would always be reasonably up-to-date.\n>\n>> So far, I have looked at the:\n>> - git-p4 documentation\n>> - Version Control with Git book By: Jon Loeliger (particularly the\n>> git-svn section)\n>> - Mailing list (particularly following thread answered by Tor Arvid Lund)\n>> - googl'n around this topic\n>>\n>> Most discussion is around how to use git-p4 as a sync mechanism for a\n>> single user. When I attempt to git-p4 clone (import) and then create a\n>> shared/bare repository out of it and emulating multiple user, the\n>> git-p4 sync mechanism breaks down after couple of merges. The git-p4\n>> sync/rebase/submit will try to reapply duplicate changes and trip\n>> pretty early in the cycle.\n>>\n>> If you have a working model of making available a p4 branch for a\n>> sub-team using git-p4, I would really appreciate a writeup or blog.\n>> Thanks in advance.\n>\n> Ok, so to make things practical, I made some simple 'rules' for myself:\n>\n> * The blessed git repo would be \"pull-only\" for the git users. That is\n> - no one pushes to that repo. It reads from p4, and the users do 'git\n> fetch/pull' from that. Nothing more, nothing less...\n>\n> * When preparing commits for upload to perforce, *always* rebase them\n> on top of the latest git-p4 tip.\n>\n> I never tried to do merges in git, and then try to turn that into\n> 'integrates' in perforce. So I always kept the perforce-things\n> 'linear' so that the communication between git and perforce should be\n> easy. IOW I always did the \"official\" branching and integrate'ing\n> using the perforce client.\n>\n> We did 'git p4 submit' directly from the users' git repos (which would\n> be synced by the blessed git repo, and from there to the other git\n> users). If you want another layer in-between [we use gerrit\n> code-review... You may have something else, or an integration manager\n> etc], you could push to another <some-project-manager-repo> and do all\n> git-p4 submits from there, I guess...\n>\n>\n> Of course, these branch/merge limitations only apply to my git history\n> at the point where I want to push to perforce. In all my daily work, I\n> create topic branches, rebase, reorder commits... all of the git\n> goodness. I simply \"linearize\" things when I want to push...\n>\n>\n> In your use-case, if you are going to do work that will result in many\n> perforce integrates, you may have a harder time with git-p4 than I\n> did, but it should be worth a try so that you can delight in daily git\n> usage instead of cursing the awfulness that is perforce.\n>\n> And yes, git-p4 does rewrite every commit after you submit it. This is\n> because of the quite simple design that was used to help git-p4 \"know\"\n> what had been synced from perforce to git. Commit messages get the\n> appended \"[git-p4: depot-paths = ... change = 12345]\" line. If git-p4\n> had been written today, this could have maybe been solved using\n> git-notes instead of rewriting commit msgs. I'm just saying... :)\n>\n> Otherwise, you will have to get around the fact that it rewrites\n> everything. For me, I have used git rebase a *lot* :)\n>\n> Good luck!\n>\n>    -- Tor Arvid\n>\n\n\n\n-- \nKaizer H. Sogiawala\n"}]}