git/list[1] front-page[2] threads[3] people[4] search[5] about
 

Re: git p4: in-place submit

From
GGGary Gibbons <ggibbons@perforce.com>
Date
May 1, 2012, 19:27 UTC
Message-ID
<5CADA0D2-54A0-4CF7-931B-1FB82B52C1E4@perforce.com>
In-Reply-To
<20120430225848.GA2727@padd.com>

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:
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
Previous: Pete Wyckoff
Message 6 of 6 in “git p4: in-place submit”
  1. Pete WyckoffApr 30, 2012
  2. Luke DiamandMay 1, 2012
  3. Pete WyckoffMay 1, 2012
  4. Gary GibbonsMay 2, 2012
  5. Pete WyckoffMay 2, 2012
  6. Gary GibbonsMay 1, 2012

Read the whole thread, see it on lore, or plain text.

$ cat FOOTERMessages come from the public archive at lore.kernel.org/git, fetched every hour. The front page is chosen and written each morning by an AI editor and can be wrong; the threads themselves are the record. About and API. For agents: an MCP server at https://gitlist.dev/mcp, and any thread, story or person page as Markdown by adding .md to its URL (or sending Accept: text/markdown). Details in /llms.txt.