I agree this is a good idea - overlapping the git and the p4 workspace. In that git p4 is creating the client ( and not the user) we can consider creating the P4 Client -> Options: with "allwrite" which would leave files writable after all p4 commands. ( that default of "noallwrite" has often produced complaints for Perforce). (I have been away and then busy on some things.. thank you very much for including me in these emails!!) Gary On Apr 30, at Apr 30 3:58 PM, Pete Wyckoff wrote: > Tell me if you think this is a good idea. > > Now, submit requires a separate workspace. You have one for git, > and a separate one used just to push files back into p4. I'd > like to see if we can do the submit part from the git workspace > directly. > > My motivation is: > > - managing both a git and a p4 workspace is extra hassle > > - $work repo is big, and having a separate copy just for > submits is a waste of space > > Setup would go something like: > > # normal clone > git p4 clone --destination=/home/pw/p4/proj //depot/proj@all > > # build client at same location > p4 client -i <<-EOF > Client: pw:proj > Description: pw proj client > Root: /home/pw/p4/proj > View: //depot/proj/... //pw:proj/... > EOF > > # set config to tell git p4 what to do > cd /home/pw/p4/proj > git config git-p4.submit-in-place true ;# new! > git config git-p4.client pw:proj > git config git-p4.useClientSpec true > > but no "p4 sync". > > Then use git to edit/commit, and eventually "git p4 submit" as > usual. The new submit-in-place code would: > > - make sure everything is committed > > - find git-p4 latest change number > - ensuring linear series of commits back to p4/master > > - warn if latest change in //depot/proj/... is greater, but proceed > > - p4 sync -k @change ;# -k means don't touch my workspace > > - for each commit in p4/master..branch: > - git checkout commit > - p4 edit, move, delete, -t text+x, etc to prepare tree > - p4 submit > - if any files require resolution, fail > - chmod +w affected files to undo p4 read-only changes > - git checkout --hard HEAD to destroy RCS keyword updates > > - if fail > - git checkout --hard HEAD > - rebase branch onto last successful commit > - else > - git p4 sync (as usual) > - update branch to p4/master > - git checkout branch > > Is this a worthwhile change? What details have I overlooked? > > -- Pete -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html