git p4: in-place submit

git p4: in-place submit

[Pete Wyckoff]

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

Re: git p4: in-place submit

[Luke Diamand]

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?

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.

Re: git p4: in-place submit

[Pete Wyckoff]

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

Re: git p4: in-place submit

[Gary Gibbons]

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.





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

Re: git p4: in-place submit

[Pete Wyckoff]

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
> 

Re: git p4: in-place submit

[Gary Gibbons]

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:

> 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