luke@xxxxxxxxxxx wrote on Tue, 01 May 2012 06:28 +0100: > On 30/04/12 23:58, 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 > > > So the trick here is the "chmod +w" - without that, you won't be > able to edit code via git? Gary: thanks for suggesting "allwrite". That feels like the obvious better alternative for this use case. The sprinkled "chmod +w" do feel a bit hacky. > I think it would be well worth doing - I've always found having two > trees a nuisance. > > It's still worth keeping the existing scheme. I often find it useful > to checkout random bits of our p4 depot without the hassle of > setting up a client workspace if I just want a read-only copy. Good point. I'll keep it optional. The other possibility is to stick the git commits into a branch somewhere, then integrate the branch in the p4 sense. This feels more complex, but makes prettier feature branches in the long-term history. -- 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