Re: git p4: in-place submit

[Pete Wyckoff <pw@padd.com>]

ggibbons@perforce.com wrote on Wed, 02 May 2012 10:06 -0700:
> Perforce 12.1 introduces a new command 'p4 reconcile'
> which 
> 
>    reconcile -- Open files for add, delete, and/or edit to reconcile
>                  client with workspace changes made outside of Perforce
> 
> This is intended to do all the work one would need to do to 
> prepare a git managed workspace for submission back into Perforce.
> 
> We could use this for in-place-submit when the p4d supports it.

Cute!  Would be nice to teach it about rename and copy too.

I would be a bit nervous of it picking up random .o files.  Maybe
it could learn to parse "git status -s", or share some common
format for other tools to explain to reconcile exactly what
happened.  Or we just feed it an explicit path list.

		-- Pete

> Entire 'p4 help reconcile':
> 
>     reconcile -- Open files for add, delete, and/or edit to reconcile
>                  client with workspace changes made outside of Perforce
> 
>     status    -- synonym for 'reconcile -n' (output uses local paths)
>     status -A -- synonym for 'reconcile -ead' (output uses local paths)
> 
>     p4 reconcile [-c changelist#] [-e -a -d -f -I -l -n] [file ...]
> 
> 	'p4 reconcile' finds unopened files in a client's workspace and
> 	detects the following:
> 
> 	1. files in depot missing from workspace, but still on have list
> 	2. files on workspace that are not in depot
> 	3. files modified in workpace that are not opened for edit
> 
> 	By default, the files matching each condition above in the path
> 	are reconciled by opening files for delete (scenario 1), add
> 	(scenario 2), and/or edit (scenario 3). The -e, -a, and -d flags
> 	may be used to limit to a subset of these operations. If no file
> 	arguments are given, reconcile and status default to the current
> 	working directory.
> 
> 	The -n flag previews the operation without performing any action.
> 
> 	If -c changelist# is included, the files are opened in the specified
> 	pending changelist.
> 
> 	The -e flag allows the user to reconcile files that have been
> 	modified outside of Perforce. The reconcile command will open
> 	these files for edit.
> 
> 	The -a flag allows the user to reconcile files that are in the
> 	user's directory that are not under Perforce source control. These
> 	files are opened for add.
> 
> 	The -f flag allows the user to add files with filenames that contain
> 	wildcard characters. Filenames that contain the special characters
> 	'@', '#', '%' or '*' are reformatted to encode the characters using
> 	ASCII hexadecimal representation.  After the files are added, you
> 	must refer to them using the reformatted file name, because Perforce
> 	does not recognize the local filesystem name.
> 
> 	The -I flag informs the client that it should not perform any ignore
> 	checking configured by P4IGNORE.
> 
> 	The -d flag allows the user to reconcile files that have been
> 	removed from the user's directory but are still in the depot.
> 	These files will be opened for delete only if they are still on the
> 	user's have list.
> 
> 	The -l flag requests output in local file syntax using relative
> 	paths, similar to the workspace-centric view provided by 'status'.
> 
> 
> 
> 
> 
> 
> On May 1, at May 1 3:18 PM, Pete Wyckoff wrote:
> 
> > luke@diamand.org 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@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>