{"thread":{"id":"8030","subject":"Yet another git perforce integration","startedAt":"2007-05-08T08:23:38Z","lastAt":"2007-05-08T12:32:53Z","messageCount":4,"participants":["Simon Hausmann","Alex Riesen"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"41426","messageId":"200705081023.38810.simon@lst.de","threadId":"8030","inReplyTo":null,"subject":"Yet another git perforce integration","fromName":"Simon Hausmann","fromEmail":"simon@lst.de","sentAt":"2007-05-08T08:23:38Z","receivedAt":"2007-05-08T08:23:38Z","isPatch":false,"sender":{"key":"hausmann@kde.org","avatar":"https://gravatar.com/avatar/bc9aad4fb31dce17eb66e690e7b51fe980c62da3c225c785da35dd806b8da778?d=mp&s=160"},"body":"Hi,\n\nIntegrations of Git with Perforce seem to be fashion these days, so I'd like \nto chip in and announce another one :)\n\nI've written a Python script called git-p4 that allows (incremental) imports \nfrom Perforce as well as submitting changes back from git into a Perforce \ndepot.\n\nIt is currently part of the fast-export repository that Chris Lee started at\n\n        http://repo.or.cz/w/fast-export.git\n\nI've been using it now for about a month for my everyday work (which requires \nPerforce), so it seems to work reasonably stable at least in my setup :)\n\nThe usage is pretty simple:\n\n        git-p4 clone //depot/path/my/project\n\nSyncing:\n\n        git-p4 sync\n\nor just\n\n        git-p4 rebase\n\nto sync and automatically rebase into the current branch (much like git-svn \nrebase :)\n\n        git-p4 submit\n\nis used to submit changes back into Perforce (use at your own risk! :)\n\nThe import itself uses git-fast-import, so it's very fast. There is also no \nneed to have the imported Perforce projects in the Perforce client view as it \njust uses \"p4 changes //depot/path\" and \"p4 \nprint //depot/path/file#revision\", which I find very convenient and still \nfast enough for use (since of course only changed files are printed).\n\nIt also doesn't require any additional meta-data. Instead every import commit \nhas a line added to the log message that contains the Perforce path the \nchangeset comes from as well as the change number. git-p4 \nsync/rebase \"parses\" this on the last commit in the \"p4\" git branch to find \nout where to continue importing for incremental imports.\n\n\nWhat's still missing is a bit of cleanup. For example I'd like to put the \nimport branch into refs/remotes instead of refs/heads, but I've had some \nproblems with fast-import when trying that. Also the support for Perforce \nbranches isn't quite working yet. I'd ideally like to for example map a \nstructure like\n\n//depot/project/main\n//depot/project/branch1\n//depot/project/branch2\n\ninto\n\nremotes/p4/main\nremotes/p4/branch1\nremotes/p4/branch2\n\nin git and still support incremental commits. But that isn't working yet ;(\n\nAlso I've never tried it on Windows and I expect problems as the script uses \npipes, calls \"patch\", etc.\n\nNevertheless I hope that this tool may be interesting for others as well.\nMaybe there's a possibility of including it in git/contrib/fast-import?\n\n\nSimon\n"},{"id":"41432","messageId":"81b0412b0705080247l2385529t61ad4ecd083261c7@mail.gmail.com","threadId":"8030","inReplyTo":"200705081023.38810.simon@lst.de","subject":"Re: Yet another git perforce integration","fromName":"Alex Riesen","fromEmail":"raa.lkml@gmail.com","sentAt":"2007-05-08T09:47:31Z","receivedAt":"2007-05-08T09:47:31Z","isPatch":false,"sender":{"key":"raa.lkml@gmail.com","avatar":"https://avatars.githubusercontent.com/u/324101?v=4"},"body":"On 5/8/07, Simon Hausmann <simon@lst.de> wrote:\n>\n> git-p4 submit\n>\n> is used to submit changes back into Perforce (use at your own risk! :)\n\nright, because you have to know where (and when) your perforce repo is,\nand then where and when your copy (in Git) is, copy the p4 changes,\nrebase your changes on top of the just copied changes (p4 history\nis linear), try to submit, watch out for fails, because someone else could\nhave submitted something, possibly resync and repeat. Cursing and\nswearing notwithstanding.\nI simplified the operation  by promising to hit everyone who submits\nanything in my domain (and was supported by the local P4 sysadms,\nso it worked).\n\n> The import itself uses git-fast-import, so it's very fast. There is also no\n> need to have the imported Perforce projects in the Perforce client view as it\n> just uses \"p4 changes //depot/path\" and \"p4\n> print //depot/path/file#revision\", which I find very convenient and still\n> fast enough for use (since of course only changed files are printed).\n\nI confirm that, but could not use the same approach in git-p4-import\nI posted earlier: I don't control the sync operation, and the stupid prog\nthat does the sync does not allow in-client operation (p4 sync -n).\nI just have to work somehow with the junk it left in working directory\n\n> It also doesn't require any additional meta-data. Instead every import commit\n> has a line added to the log message that contains the Perforce path the\n> changeset comes from as well as the change number. git-p4\n> sync/rebase \"parses\" this on the last commit in the \"p4\" git branch to find\n> out where to continue importing for incremental imports.\n\nHow do you handle that patchwork of mappings synced to diverse revisions\nthat P4 clients tend to become? Don't you have to save change number or\nrevision for _each_ file?\n\n> What's still missing is a bit of cleanup. For example I'd like to put the\n> import branch into refs/remotes instead of refs/heads, but I've had some\n> problems with fast-import when trying that. Also the support for Perforce\n> branches isn't quite working yet.\n\nAFACS, it is impossible: Perforce does not have branches (in Git's meaning\nof the word). It only has directories. Integration (it is something like\n\"in-repo-copy\") metadata are just duct-taped on it (that stupid branchspec).\n\n> Also I've never tried it on Windows and I expect problems as the script uses\n> pipes, calls \"patch\", etc.\n\n...and case-sensitivity. BTW, how does your script handle filenames with\nspecial characters and spaces in them?\n"},{"id":"41439","messageId":"200705081249.36214.simon@lst.de","threadId":"8030","inReplyTo":"81b0412b0705080247l2385529t61ad4ecd083261c7@mail.gmail.com","subject":"Re: Yet another git perforce integration","fromName":"Simon Hausmann","fromEmail":"simon@lst.de","sentAt":"2007-05-08T10:49:35Z","receivedAt":"2007-05-08T10:49:35Z","isPatch":false,"sender":{"key":"hausmann@kde.org","avatar":"https://gravatar.com/avatar/bc9aad4fb31dce17eb66e690e7b51fe980c62da3c225c785da35dd806b8da778?d=mp&s=160"},"body":"On Tuesday 08 May 2007 11:47:31 Alex Riesen wrote:\n> On 5/8/07, Simon Hausmann <simon@lst.de> wrote:\n> > git-p4 submit\n> >\n> > is used to submit changes back into Perforce (use at your own risk! :)\n>\n> right, because you have to know where (and when) your perforce repo is,\n> and then where and when your copy (in Git) is, copy the p4 changes,\n> rebase your changes on top of the just copied changes (p4 history\n> is linear), try to submit, watch out for fails, because someone else could\n> have submitted something, possibly resync and repeat. Cursing and\n> swearing notwithstanding.\n\nYeah, it's a bit tricky. I'm using \"p4 where\" to locate the p4 checkout and \nsubmitting back to perforce is an interactive process for me. The user is \npresented with the entire diff for each change as well as the log message in \nan editor and can also abort/continue in-between. In real-life usage I've \nfound it to be fairly smooth though (no or only few conflits), but then I \nguess it depends also on the number of people working on the depot as a whole \nat the same time :)\n\n> > It also doesn't require any additional meta-data. Instead every import\n> > commit has a line added to the log message that contains the Perforce\n> > path the changeset comes from as well as the change number. git-p4\n> > sync/rebase \"parses\" this on the last commit in the \"p4\" git branch to\n> > find out where to continue importing for incremental imports.\n>\n> How do you handle that patchwork of mappings synced to diverse revisions\n> that P4 clients tend to become? Don't you have to save change number or\n> revision for _each_ file?\n\nI'm not sure I understand the question. I don't really use the p4 client view \nat all. I know the last imported p4 change number from the top commit in the \ngit \"p4\" branch. Then I use \"p4 changes //depot/path/@lastchangenum,#head\" to \nget the list of changes that need to be imported. For each change I look at \nthe list of affected files using \"p4 describe\" and feed each file using \"p4 \nprint\" into git-fast-import. None of these import operations require anything \nfrom the client view/mapping.\n\nOnly when submitting changes back to Perforce the corresponding depot path \nmust be checked out /somewhere/ (!= git repository), so that \"p4 \nwhere //depot/path\" reports it. But then I just offer the user to run \"p4 \nsync\" before applying the changes from git.\n\nI guess the feasibility may very well depend a bit on the development model \nused with p4. I don't know if there are many models, but for example we have \na fairly linear model where it's normal to be at the #head revision, don't \nuse a whole lot of branches in Perforce. So p4 users are used to running \"p4 \nresolve\" and I personally got used to git conflict resolving through \"git \nrebase\" :)\n\n> > What's still missing is a bit of cleanup. For example I'd like to put the\n> > import branch into refs/remotes instead of refs/heads, but I've had some\n> > problems with fast-import when trying that. Also the support for Perforce\n> > branches isn't quite working yet.\n>\n> AFACS, it is impossible: Perforce does not have branches (in Git's meaning\n> of the word). It only has directories. Integration (it is something like\n> \"in-repo-copy\") metadata are just duct-taped on it (that stupid\n> branchspec).\n\nTrue, it probably depends a bit on the depot organization. For example we have\n//depot/qt/main and then branches like //depot/qt/4.3 or research branches \nlike //depot/qt/research/somecoolfeature . That's the kind of structure I'd \nlike to map to git, and merges /could/ be detected from integrations if after \na commit that has integrations between these \"known\" branches all revisions \nof all files are integrated. But that's obviously a very slow operation and I \ncurrently don't think it's worth it. But of course detecting the initial \nbranch point is easy and fast and that is worth it (to record the branch \ncreation, there's no merge of course).\n\n> > Also I've never tried it on Windows and I expect problems as the script\n> > uses pipes, calls \"patch\", etc.\n>\n> ...and case-sensitivity. BTW, how does your script handle filenames with\n> special characters and spaces in them?\n\nI don't really treat them special. I get the file name from the output of \"p4 \ndescribe\" (using the Guido option :) and pass it on to git-fast-import.\n\nSimon\n"},{"id":"41446","messageId":"81b0412b0705080532o14db3b24l1a71409af1c443ae@mail.gmail.com","threadId":"8030","inReplyTo":"200705081249.36214.simon@lst.de","subject":"Re: Yet another git perforce integration","fromName":"Alex Riesen","fromEmail":"raa.lkml@gmail.com","sentAt":"2007-05-08T12:32:53Z","receivedAt":"2007-05-08T12:32:53Z","isPatch":false,"sender":{"key":"raa.lkml@gmail.com","avatar":"https://avatars.githubusercontent.com/u/324101?v=4"},"body":"On 5/8/07, Simon Hausmann <simon@lst.de> wrote:\n> > > It also doesn't require any additional meta-data. Instead every import\n> > > commit has a line added to the log message that contains the Perforce\n> > > path the changeset comes from as well as the change number. git-p4\n> > > sync/rebase \"parses\" this on the last commit in the \"p4\" git branch to\n> > > find out where to continue importing for incremental imports.\n> >\n> > How do you handle that patchwork of mappings synced to diverse revisions\n> > that P4 clients tend to become? Don't you have to save change number or\n> > revision for _each_ file?\n>\n> I'm not sure I understand the question. I don't really use the p4 client view\n> at all. ...\n\nAh, you're _that_ lucky...\n\n> > > problems with fast-import when trying that. Also the support for Perforce\n> > > branches isn't quite working yet.\n> >\n> > AFACS, it is impossible: Perforce does not have branches (in Git's meaning\n> > of the word). It only has directories. Integration (it is something like\n> > \"in-repo-copy\") metadata are just duct-taped on it (that stupid\n> > branchspec).\n>\n> True, it probably depends a bit on the depot organization. For example we have\n> //depot/qt/main and then branches like //depot/qt/4.3 or research branches\n> like //depot/qt/research/somecoolfeature . That's the kind of structure I'd\n> like to map to git, ...\n\nRecreating it anywhere, not just in Git, would be stupid. As it is in Perforce.\n\n> > > Also I've never tried it on Windows and I expect problems as the script\n> > > uses pipes, calls \"patch\", etc.\n> >\n> > ...and case-sensitivity. BTW, how does your script handle filenames with\n> > special characters and spaces in them?\n>\n> I don't really treat them special. I get the file name from the output of \"p4\n> describe\" (using the Guido option :) and pass it on to git-fast-import.\n>\n\nYou seem to assume that the names never contain double quotes and\nbackslashes. For example in the names of directories.\n"}]}