{"thread":{"id":"30374","subject":"git p4: in-place submit","startedAt":"2012-04-30T22:58:48Z","lastAt":"2012-05-02T22:19:32Z","messageCount":6,"participants":["Pete Wyckoff","Luke Diamand","Gary Gibbons"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"190363","messageId":"20120430225848.GA2727@padd.com","threadId":"30374","inReplyTo":null,"subject":"git p4: in-place submit","fromName":"Pete Wyckoff","fromEmail":"pw@padd.com","sentAt":"2012-04-30T22:58:48Z","receivedAt":"2012-04-30T22:58:48Z","isPatch":false,"sender":{"key":"pw@padd.com","avatar":null},"body":"Tell me if you think this is a good idea.\n\nNow, submit requires a separate workspace.  You have one for git,\nand a separate one used just to push files back into p4.  I'd\nlike to see if we can do the submit part from the git workspace\ndirectly.\n\nMy motivation is:\n\n    - managing both a git and a p4 workspace is extra hassle\n\n    - $work repo is big, and having a separate copy just for\n      submits is a waste of space\n\nSetup would go something like:\n\n        # normal clone\n        git p4 clone --destination=/home/pw/p4/proj //depot/proj@all\n\n        # build client at same location\n        p4 client -i <<-EOF\n        Client: pw:proj\n        Description: pw proj client\n        Root: /home/pw/p4/proj\n        View: //depot/proj/... //pw:proj/...\n        EOF\n\n        # set config to tell git p4 what to do\n        cd /home/pw/p4/proj\n        git config git-p4.submit-in-place true   ;# new!\n        git config git-p4.client pw:proj\n        git config git-p4.useClientSpec true\n\nbut no \"p4 sync\".\n\nThen use git to edit/commit, and eventually \"git p4 submit\" as\nusual.  The new submit-in-place code would:\n\n    - make sure everything is committed\n\n    - find git-p4 latest change number\n        - ensuring linear series of commits back to p4/master\n\n    - warn if latest change in //depot/proj/... is greater, but proceed\n\n    - p4 sync -k @change  ;# -k means don't touch my workspace\n\n    - for each commit in p4/master..branch:\n        - git checkout commit\n        - p4 edit, move, delete, -t text+x, etc to prepare tree\n        - p4 submit\n        - if any files require resolution, fail\n        - chmod +w affected files to undo p4 read-only changes\n        - git checkout --hard HEAD to destroy RCS keyword updates\n\n    - if fail\n        - git checkout --hard HEAD\n        - rebase branch onto last successful commit\n    - else\n        - git p4 sync (as usual)\n        - update branch to p4/master\n        - git checkout branch\n\nIs this a worthwhile change?  What details have I overlooked?\n\n                -- Pete\n"},{"id":"190395","messageId":"4F9F7497.5050504@diamand.org","threadId":"30374","inReplyTo":"20120430225848.GA2727@padd.com","subject":"Re: git p4: in-place submit","fromName":"Luke Diamand","fromEmail":"luke@diamand.org","sentAt":"2012-05-01T05:28:55Z","receivedAt":"2012-05-01T05:28:55Z","isPatch":false,"sender":{"key":"luke@diamand.org","avatar":"https://avatars.githubusercontent.com/u/5330967?v=4"},"body":"On 30/04/12 23:58, Pete Wyckoff wrote:\n> Tell me if you think this is a good idea.\n>\n> Now, submit requires a separate workspace.  You have one for git,\n> and a separate one used just to push files back into p4.  I'd\n> like to see if we can do the submit part from the git workspace\n> directly.\n>\n> My motivation is:\n>\n>      - managing both a git and a p4 workspace is extra hassle\n>\n>      - $work repo is big, and having a separate copy just for\n>        submits is a waste of space\n>\n> Setup would go something like:\n>\n>          # normal clone\n>          git p4 clone --destination=/home/pw/p4/proj //depot/proj@all\n>\n>          # build client at same location\n>          p4 client -i<<-EOF\n>          Client: pw:proj\n>          Description: pw proj client\n>          Root: /home/pw/p4/proj\n>          View: //depot/proj/... //pw:proj/...\n>          EOF\n>\n>          # set config to tell git p4 what to do\n>          cd /home/pw/p4/proj\n>          git config git-p4.submit-in-place true   ;# new!\n>          git config git-p4.client pw:proj\n>          git config git-p4.useClientSpec true\n>\n> but no \"p4 sync\".\n>\n> Then use git to edit/commit, and eventually \"git p4 submit\" as\n> usual.  The new submit-in-place code would:\n>\n>      - make sure everything is committed\n>\n>      - find git-p4 latest change number\n>          - ensuring linear series of commits back to p4/master\n>\n>      - warn if latest change in //depot/proj/... is greater, but proceed\n>\n>      - p4 sync -k @change  ;# -k means don't touch my workspace\n>\n>      - for each commit in p4/master..branch:\n>          - git checkout commit\n>          - p4 edit, move, delete, -t text+x, etc to prepare tree\n>          - p4 submit\n>          - if any files require resolution, fail\n>          - chmod +w affected files to undo p4 read-only changes\n>          - git checkout --hard HEAD to destroy RCS keyword updates\n>\n>      - if fail\n>          - git checkout --hard HEAD\n>          - rebase branch onto last successful commit\n>      - else\n>          - git p4 sync (as usual)\n>          - update branch to p4/master\n>          - git checkout branch\n>\n> Is this a worthwhile change?  What details have I overlooked?\n>\n>                  -- Pete\n\n\nSo the trick here is the \"chmod +w\" - without that, you won't be able to \nedit code via git?\n\nI think it would be well worth doing - I've always found having two \ntrees a nuisance.\n\nIt's still worth keeping the existing scheme. I often find it useful to \ncheckout random bits of our p4 depot without the hassle of setting up a \nclient workspace if I just want a read-only copy.\n"},{"id":"190468","messageId":"5CADA0D2-54A0-4CF7-931B-1FB82B52C1E4@perforce.com","threadId":"30374","inReplyTo":"20120430225848.GA2727@padd.com","subject":"Re: git p4: in-place submit","fromName":"Gary Gibbons","fromEmail":"ggibbons@perforce.com","sentAt":"2012-05-01T19:27:42Z","receivedAt":"2012-05-01T19:27:42Z","isPatch":false,"sender":{"key":"ggibbons@perforce.com","avatar":null},"body":"I agree this is a good idea - overlapping the git and the p4 workspace.\nIn that git p4 is creating the client ( and not the user)\nwe can consider creating the P4 Client ->  Options: with \"allwrite\" which would leave files writable\nafter all p4 commands. ( that default of \"noallwrite\" has often produced complaints for Perforce).\n\n\n\n\n(I have been away and then busy on some things.. thank you very much for including me in these emails!!)\n\nGary\n\n\n\n\nOn Apr 30, at Apr 30 3:58 PM, Pete Wyckoff wrote:\n\n> Tell me if you think this is a good idea.\n> \n> Now, submit requires a separate workspace.  You have one for git,\n> and a separate one used just to push files back into p4.  I'd\n> like to see if we can do the submit part from the git workspace\n> directly.\n> \n> My motivation is:\n> \n>    - managing both a git and a p4 workspace is extra hassle\n> \n>    - $work repo is big, and having a separate copy just for\n>      submits is a waste of space\n> \n> Setup would go something like:\n> \n>        # normal clone\n>        git p4 clone --destination=/home/pw/p4/proj //depot/proj@all\n> \n>        # build client at same location\n>        p4 client -i <<-EOF\n>        Client: pw:proj\n>        Description: pw proj client\n>        Root: /home/pw/p4/proj\n>        View: //depot/proj/... //pw:proj/...\n>        EOF\n> \n>        # set config to tell git p4 what to do\n>        cd /home/pw/p4/proj\n>        git config git-p4.submit-in-place true   ;# new!\n>        git config git-p4.client pw:proj\n>        git config git-p4.useClientSpec true\n> \n> but no \"p4 sync\".\n> \n> Then use git to edit/commit, and eventually \"git p4 submit\" as\n> usual.  The new submit-in-place code would:\n> \n>    - make sure everything is committed\n> \n>    - find git-p4 latest change number\n>        - ensuring linear series of commits back to p4/master\n> \n>    - warn if latest change in //depot/proj/... is greater, but proceed\n> \n>    - p4 sync -k @change  ;# -k means don't touch my workspace\n> \n>    - for each commit in p4/master..branch:\n>        - git checkout commit\n>        - p4 edit, move, delete, -t text+x, etc to prepare tree\n>        - p4 submit\n>        - if any files require resolution, fail\n>        - chmod +w affected files to undo p4 read-only changes\n>        - git checkout --hard HEAD to destroy RCS keyword updates\n> \n>    - if fail\n>        - git checkout --hard HEAD\n>        - rebase branch onto last successful commit\n>    - else\n>        - git p4 sync (as usual)\n>        - update branch to p4/master\n>        - git checkout branch\n> \n> Is this a worthwhile change?  What details have I overlooked?\n> \n>                -- Pete\n"},{"id":"190499","messageId":"20120501221847.GA8357@padd.com","threadId":"30374","inReplyTo":"4F9F7497.5050504@diamand.org","subject":"Re: git p4: in-place submit","fromName":"Pete Wyckoff","fromEmail":"pw@padd.com","sentAt":"2012-05-01T22:18:47Z","receivedAt":"2012-05-01T22:18:47Z","isPatch":false,"sender":{"key":"pw@padd.com","avatar":null},"body":"luke@diamand.org wrote on Tue, 01 May 2012 06:28 +0100:\n> On 30/04/12 23:58, Pete Wyckoff wrote:\n> >Tell me if you think this is a good idea.\n> >\n> >Now, submit requires a separate workspace.  You have one for git,\n> >and a separate one used just to push files back into p4.  I'd\n> >like to see if we can do the submit part from the git workspace\n> >directly.\n> >\n> >My motivation is:\n> >\n> >     - managing both a git and a p4 workspace is extra hassle\n> >\n> >     - $work repo is big, and having a separate copy just for\n> >       submits is a waste of space\n> >\n> >Setup would go something like:\n> >\n> >         # normal clone\n> >         git p4 clone --destination=/home/pw/p4/proj //depot/proj@all\n> >\n> >         # build client at same location\n> >         p4 client -i<<-EOF\n> >         Client: pw:proj\n> >         Description: pw proj client\n> >         Root: /home/pw/p4/proj\n> >         View: //depot/proj/... //pw:proj/...\n> >         EOF\n> >\n> >         # set config to tell git p4 what to do\n> >         cd /home/pw/p4/proj\n> >         git config git-p4.submit-in-place true   ;# new!\n> >         git config git-p4.client pw:proj\n> >         git config git-p4.useClientSpec true\n> >\n> >but no \"p4 sync\".\n> >\n> >Then use git to edit/commit, and eventually \"git p4 submit\" as\n> >usual.  The new submit-in-place code would:\n> >\n> >     - make sure everything is committed\n> >\n> >     - find git-p4 latest change number\n> >         - ensuring linear series of commits back to p4/master\n> >\n> >     - warn if latest change in //depot/proj/... is greater, but proceed\n> >\n> >     - p4 sync -k @change  ;# -k means don't touch my workspace\n> >\n> >     - for each commit in p4/master..branch:\n> >         - git checkout commit\n> >         - p4 edit, move, delete, -t text+x, etc to prepare tree\n> >         - p4 submit\n> >         - if any files require resolution, fail\n> >         - chmod +w affected files to undo p4 read-only changes\n> >         - git checkout --hard HEAD to destroy RCS keyword updates\n> >\n> >     - if fail\n> >         - git checkout --hard HEAD\n> >         - rebase branch onto last successful commit\n> >     - else\n> >         - git p4 sync (as usual)\n> >         - update branch to p4/master\n> >         - git checkout branch\n> >\n> >Is this a worthwhile change?  What details have I overlooked?\n> >\n> >                 -- Pete\n> \n> \n> So the trick here is the \"chmod +w\" - without that, you won't be\n> able to edit code via git?\n\nGary: thanks for suggesting \"allwrite\".  That feels like the\nobvious better alternative for this use case.  The sprinkled\n\"chmod +w\" do feel a bit hacky.\n\n> I think it would be well worth doing - I've always found having two\n> trees a nuisance.\n> \n> It's still worth keeping the existing scheme. I often find it useful\n> to checkout random bits of our p4 depot without the hassle of\n> setting up a client workspace if I just want a read-only copy.\n\nGood point.  I'll keep it optional.\n\nThe other possibility is to stick the git commits into a branch\nsomewhere, then integrate the branch in the p4 sense.  This feels\nmore complex, but makes prettier feature branches in the\nlong-term history.\n\n\t\t-- Pete\n"},{"id":"190578","messageId":"B4B1DDAA-FA1A-4CAB-81BB-ED1D42FAFB43@perforce.com","threadId":"30374","inReplyTo":"20120501221847.GA8357@padd.com","subject":"Re: git p4: in-place submit","fromName":"Gary Gibbons","fromEmail":"ggibbons@perforce.com","sentAt":"2012-05-02T17:06:19Z","receivedAt":"2012-05-02T17:06:19Z","isPatch":false,"sender":{"key":"ggibbons@perforce.com","avatar":null},"body":"Perforce 12.1 introduces a new command 'p4 reconcile'\nwhich \n\n   reconcile -- Open files for add, delete, and/or edit to reconcile\n                 client with workspace changes made outside of Perforce\n\nThis is intended to do all the work one would need to do to \nprepare a git managed workspace for submission back into Perforce.\n\nWe could use this for in-place-submit when the p4d supports it.\n\n\n\n\n\nEntire 'p4 help reconcile':\n\n    reconcile -- Open files for add, delete, and/or edit to reconcile\n                 client with workspace changes made outside of Perforce\n\n    status    -- synonym for 'reconcile -n' (output uses local paths)\n    status -A -- synonym for 'reconcile -ead' (output uses local paths)\n\n    p4 reconcile [-c changelist#] [-e -a -d -f -I -l -n] [file ...]\n\n\t'p4 reconcile' finds unopened files in a client's workspace and\n\tdetects the following:\n\n\t1. files in depot missing from workspace, but still on have list\n\t2. files on workspace that are not in depot\n\t3. files modified in workpace that are not opened for edit\n\n\tBy default, the files matching each condition above in the path\n\tare reconciled by opening files for delete (scenario 1), add\n\t(scenario 2), and/or edit (scenario 3). The -e, -a, and -d flags\n\tmay be used to limit to a subset of these operations. If no file\n\targuments are given, reconcile and status default to the current\n\tworking directory.\n\n\tThe -n flag previews the operation without performing any action.\n\n\tIf -c changelist# is included, the files are opened in the specified\n\tpending changelist.\n\n\tThe -e flag allows the user to reconcile files that have been\n\tmodified outside of Perforce. The reconcile command will open\n\tthese files for edit.\n\n\tThe -a flag allows the user to reconcile files that are in the\n\tuser's directory that are not under Perforce source control. These\n\tfiles are opened for add.\n\n\tThe -f flag allows the user to add files with filenames that contain\n\twildcard characters. Filenames that contain the special characters\n\t'@', '#', '%' or '*' are reformatted to encode the characters using\n\tASCII hexadecimal representation.  After the files are added, you\n\tmust refer to them using the reformatted file name, because Perforce\n\tdoes not recognize the local filesystem name.\n\n\tThe -I flag informs the client that it should not perform any ignore\n\tchecking configured by P4IGNORE.\n\n\tThe -d flag allows the user to reconcile files that have been\n\tremoved from the user's directory but are still in the depot.\n\tThese files will be opened for delete only if they are still on the\n\tuser's have list.\n\n\tThe -l flag requests output in local file syntax using relative\n\tpaths, similar to the workspace-centric view provided by 'status'.\n\n\n\n\n\n\nOn May 1, at May 1 3:18 PM, Pete Wyckoff wrote:\n\n> luke@diamand.org wrote on Tue, 01 May 2012 06:28 +0100:\n>> On 30/04/12 23:58, Pete Wyckoff wrote:\n>>> Tell me if you think this is a good idea.\n>>> \n>>> Now, submit requires a separate workspace.  You have one for git,\n>>> and a separate one used just to push files back into p4.  I'd\n>>> like to see if we can do the submit part from the git workspace\n>>> directly.\n>>> \n>>> My motivation is:\n>>> \n>>>    - managing both a git and a p4 workspace is extra hassle\n>>> \n>>>    - $work repo is big, and having a separate copy just for\n>>>      submits is a waste of space\n>>> \n>>> Setup would go something like:\n>>> \n>>>        # normal clone\n>>>        git p4 clone --destination=/home/pw/p4/proj //depot/proj@all\n>>> \n>>>        # build client at same location\n>>>        p4 client -i<<-EOF\n>>>        Client: pw:proj\n>>>        Description: pw proj client\n>>>        Root: /home/pw/p4/proj\n>>>        View: //depot/proj/... //pw:proj/...\n>>>        EOF\n>>> \n>>>        # set config to tell git p4 what to do\n>>>        cd /home/pw/p4/proj\n>>>        git config git-p4.submit-in-place true   ;# new!\n>>>        git config git-p4.client pw:proj\n>>>        git config git-p4.useClientSpec true\n>>> \n>>> but no \"p4 sync\".\n>>> \n>>> Then use git to edit/commit, and eventually \"git p4 submit\" as\n>>> usual.  The new submit-in-place code would:\n>>> \n>>>    - make sure everything is committed\n>>> \n>>>    - find git-p4 latest change number\n>>>        - ensuring linear series of commits back to p4/master\n>>> \n>>>    - warn if latest change in //depot/proj/... is greater, but proceed\n>>> \n>>>    - p4 sync -k @change  ;# -k means don't touch my workspace\n>>> \n>>>    - for each commit in p4/master..branch:\n>>>        - git checkout commit\n>>>        - p4 edit, move, delete, -t text+x, etc to prepare tree\n>>>        - p4 submit\n>>>        - if any files require resolution, fail\n>>>        - chmod +w affected files to undo p4 read-only changes\n>>>        - git checkout --hard HEAD to destroy RCS keyword updates\n>>> \n>>>    - if fail\n>>>        - git checkout --hard HEAD\n>>>        - rebase branch onto last successful commit\n>>>    - else\n>>>        - git p4 sync (as usual)\n>>>        - update branch to p4/master\n>>>        - git checkout branch\n>>> \n>>> Is this a worthwhile change?  What details have I overlooked?\n>>> \n>>>                -- Pete\n>> \n>> \n>> So the trick here is the \"chmod +w\" - without that, you won't be\n>> able to edit code via git?\n> \n> Gary: thanks for suggesting \"allwrite\".  That feels like the\n> obvious better alternative for this use case.  The sprinkled\n> \"chmod +w\" do feel a bit hacky.\n> \n>> I think it would be well worth doing - I've always found having two\n>> trees a nuisance.\n>> \n>> It's still worth keeping the existing scheme. I often find it useful\n>> to checkout random bits of our p4 depot without the hassle of\n>> setting up a client workspace if I just want a read-only copy.\n> \n> Good point.  I'll keep it optional.\n> \n> The other possibility is to stick the git commits into a branch\n> somewhere, then integrate the branch in the p4 sense.  This feels\n> more complex, but makes prettier feature branches in the\n> long-term history.\n> \n> \t\t-- Pete\n"},{"id":"190602","messageId":"20120502221932.GA6208@padd.com","threadId":"30374","inReplyTo":"B4B1DDAA-FA1A-4CAB-81BB-ED1D42FAFB43@perforce.com","subject":"Re: git p4: in-place submit","fromName":"Pete Wyckoff","fromEmail":"pw@padd.com","sentAt":"2012-05-02T22:19:32Z","receivedAt":"2012-05-02T22:19:32Z","isPatch":false,"sender":{"key":"pw@padd.com","avatar":null},"body":"ggibbons@perforce.com wrote on Wed, 02 May 2012 10:06 -0700:\n> Perforce 12.1 introduces a new command 'p4 reconcile'\n> which \n> \n>    reconcile -- Open files for add, delete, and/or edit to reconcile\n>                  client with workspace changes made outside of Perforce\n> \n> This is intended to do all the work one would need to do to \n> prepare a git managed workspace for submission back into Perforce.\n> \n> We could use this for in-place-submit when the p4d supports it.\n\nCute!  Would be nice to teach it about rename and copy too.\n\nI would be a bit nervous of it picking up random .o files.  Maybe\nit could learn to parse \"git status -s\", or share some common\nformat for other tools to explain to reconcile exactly what\nhappened.  Or we just feed it an explicit path list.\n\n\t\t-- Pete\n\n> Entire 'p4 help reconcile':\n> \n>     reconcile -- Open files for add, delete, and/or edit to reconcile\n>                  client with workspace changes made outside of Perforce\n> \n>     status    -- synonym for 'reconcile -n' (output uses local paths)\n>     status -A -- synonym for 'reconcile -ead' (output uses local paths)\n> \n>     p4 reconcile [-c changelist#] [-e -a -d -f -I -l -n] [file ...]\n> \n> \t'p4 reconcile' finds unopened files in a client's workspace and\n> \tdetects the following:\n> \n> \t1. files in depot missing from workspace, but still on have list\n> \t2. files on workspace that are not in depot\n> \t3. files modified in workpace that are not opened for edit\n> \n> \tBy default, the files matching each condition above in the path\n> \tare reconciled by opening files for delete (scenario 1), add\n> \t(scenario 2), and/or edit (scenario 3). The -e, -a, and -d flags\n> \tmay be used to limit to a subset of these operations. If no file\n> \targuments are given, reconcile and status default to the current\n> \tworking directory.\n> \n> \tThe -n flag previews the operation without performing any action.\n> \n> \tIf -c changelist# is included, the files are opened in the specified\n> \tpending changelist.\n> \n> \tThe -e flag allows the user to reconcile files that have been\n> \tmodified outside of Perforce. The reconcile command will open\n> \tthese files for edit.\n> \n> \tThe -a flag allows the user to reconcile files that are in the\n> \tuser's directory that are not under Perforce source control. These\n> \tfiles are opened for add.\n> \n> \tThe -f flag allows the user to add files with filenames that contain\n> \twildcard characters. Filenames that contain the special characters\n> \t'@', '#', '%' or '*' are reformatted to encode the characters using\n> \tASCII hexadecimal representation.  After the files are added, you\n> \tmust refer to them using the reformatted file name, because Perforce\n> \tdoes not recognize the local filesystem name.\n> \n> \tThe -I flag informs the client that it should not perform any ignore\n> \tchecking configured by P4IGNORE.\n> \n> \tThe -d flag allows the user to reconcile files that have been\n> \tremoved from the user's directory but are still in the depot.\n> \tThese files will be opened for delete only if they are still on the\n> \tuser's have list.\n> \n> \tThe -l flag requests output in local file syntax using relative\n> \tpaths, similar to the workspace-centric view provided by 'status'.\n> \n> \n> \n> \n> \n> \n> On May 1, at May 1 3:18 PM, Pete Wyckoff wrote:\n> \n> > luke@diamand.org wrote on Tue, 01 May 2012 06:28 +0100:\n> >> On 30/04/12 23:58, Pete Wyckoff wrote:\n> >>> Tell me if you think this is a good idea.\n> >>> \n> >>> Now, submit requires a separate workspace.  You have one for git,\n> >>> and a separate one used just to push files back into p4.  I'd\n> >>> like to see if we can do the submit part from the git workspace\n> >>> directly.\n> >>> \n> >>> My motivation is:\n> >>> \n> >>>    - managing both a git and a p4 workspace is extra hassle\n> >>> \n> >>>    - $work repo is big, and having a separate copy just for\n> >>>      submits is a waste of space\n> >>> \n> >>> Setup would go something like:\n> >>> \n> >>>        # normal clone\n> >>>        git p4 clone --destination=/home/pw/p4/proj //depot/proj@all\n> >>> \n> >>>        # build client at same location\n> >>>        p4 client -i<<-EOF\n> >>>        Client: pw:proj\n> >>>        Description: pw proj client\n> >>>        Root: /home/pw/p4/proj\n> >>>        View: //depot/proj/... //pw:proj/...\n> >>>        EOF\n> >>> \n> >>>        # set config to tell git p4 what to do\n> >>>        cd /home/pw/p4/proj\n> >>>        git config git-p4.submit-in-place true   ;# new!\n> >>>        git config git-p4.client pw:proj\n> >>>        git config git-p4.useClientSpec true\n> >>> \n> >>> but no \"p4 sync\".\n> >>> \n> >>> Then use git to edit/commit, and eventually \"git p4 submit\" as\n> >>> usual.  The new submit-in-place code would:\n> >>> \n> >>>    - make sure everything is committed\n> >>> \n> >>>    - find git-p4 latest change number\n> >>>        - ensuring linear series of commits back to p4/master\n> >>> \n> >>>    - warn if latest change in //depot/proj/... is greater, but proceed\n> >>> \n> >>>    - p4 sync -k @change  ;# -k means don't touch my workspace\n> >>> \n> >>>    - for each commit in p4/master..branch:\n> >>>        - git checkout commit\n> >>>        - p4 edit, move, delete, -t text+x, etc to prepare tree\n> >>>        - p4 submit\n> >>>        - if any files require resolution, fail\n> >>>        - chmod +w affected files to undo p4 read-only changes\n> >>>        - git checkout --hard HEAD to destroy RCS keyword updates\n> >>> \n> >>>    - if fail\n> >>>        - git checkout --hard HEAD\n> >>>        - rebase branch onto last successful commit\n> >>>    - else\n> >>>        - git p4 sync (as usual)\n> >>>        - update branch to p4/master\n> >>>        - git checkout branch\n> >>> \n> >>> Is this a worthwhile change?  What details have I overlooked?\n> >>> \n> >>>                -- Pete\n> >> \n> >> \n> >> So the trick here is the \"chmod +w\" - without that, you won't be\n> >> able to edit code via git?\n> > \n> > Gary: thanks for suggesting \"allwrite\".  That feels like the\n> > obvious better alternative for this use case.  The sprinkled\n> > \"chmod +w\" do feel a bit hacky.\n> > \n> >> I think it would be well worth doing - I've always found having two\n> >> trees a nuisance.\n> >> \n> >> It's still worth keeping the existing scheme. I often find it useful\n> >> to checkout random bits of our p4 depot without the hassle of\n> >> setting up a client workspace if I just want a read-only copy.\n> > \n> > Good point.  I'll keep it optional.\n> > \n> > The other possibility is to stick the git commits into a branch\n> > somewhere, then integrate the branch in the p4 sense.  This feels\n> > more complex, but makes prettier feature branches in the\n> > long-term history.\n> > \n> > \t\t-- Pete\n> \n> --\n> To unsubscribe from this list: send the line \"unsubscribe git\" in\n> the body of a message to majordomo@vger.kernel.org\n> More majordomo info at  http://vger.kernel.org/majordomo-info.html\n> \n"}]}