Re: git p4: in-place submit

From: Luke Diamand <luke@diamand.org>
Date: May 1, 2012, 05:28 UTC
Message-ID: <4F9F7497.5050504@diamand.org>
In-Reply-To: <20120430225848.GA2727@padd.com>

On 30/04/12 23:58, Pete Wyckoff wrote:

Show 66 quoted lines

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

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.