Re: git p4: in-place submit

From: Pete Wyckoff <pw@padd.com>
Date: May 1, 2012, 22:18 UTC
Message-ID: <20120501221847.GA8357@padd.com>
In-Reply-To: <4F9F7497.5050504@diamand.org>

luke@diamand.org wrote on Tue, 01 May 2012 06:28 +0100:

Show 71 quoted lines

> 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.

Show 6 quoted lines

> 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