* git p4: in-place submit
@ 2012-04-30 22:58 Pete Wyckoff
2012-05-01 5:28 ` Luke Diamand
2012-05-01 19:27 ` Gary Gibbons
0 siblings, 2 replies; 6+ messages in thread
From: Pete Wyckoff @ 2012-04-30 22:58 UTC (permalink / raw)
To: git; +Cc: Luke Diamand, Vitor Antunes, Michael Horowitz, Gary Gibbons
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
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: git p4: in-place submit
2012-04-30 22:58 git p4: in-place submit Pete Wyckoff
@ 2012-05-01 5:28 ` Luke Diamand
2012-05-01 22:18 ` Pete Wyckoff
2012-05-01 19:27 ` Gary Gibbons
1 sibling, 1 reply; 6+ messages in thread
From: Luke Diamand @ 2012-05-01 5:28 UTC (permalink / raw)
To: Pete Wyckoff; +Cc: git, Vitor Antunes, Michael Horowitz, Gary Gibbons
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.
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: git p4: in-place submit
2012-04-30 22:58 git p4: in-place submit Pete Wyckoff
2012-05-01 5:28 ` Luke Diamand
@ 2012-05-01 19:27 ` Gary Gibbons
1 sibling, 0 replies; 6+ messages in thread
From: Gary Gibbons @ 2012-05-01 19:27 UTC (permalink / raw)
To: Pete Wyckoff; +Cc: git, Luke Diamand, Vitor Antunes, Michael Horowitz
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
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: git p4: in-place submit
2012-05-01 5:28 ` Luke Diamand
@ 2012-05-01 22:18 ` Pete Wyckoff
2012-05-02 17:06 ` Gary Gibbons
0 siblings, 1 reply; 6+ messages in thread
From: Pete Wyckoff @ 2012-05-01 22:18 UTC (permalink / raw)
To: Luke Diamand, Gary Gibbons; +Cc: git, Vitor Antunes, Michael Horowitz
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
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: git p4: in-place submit
2012-05-01 22:18 ` Pete Wyckoff
@ 2012-05-02 17:06 ` Gary Gibbons
2012-05-02 22:19 ` Pete Wyckoff
0 siblings, 1 reply; 6+ messages in thread
From: Gary Gibbons @ 2012-05-02 17:06 UTC (permalink / raw)
To: Pete Wyckoff; +Cc: Luke Diamand, git, Vitor Antunes, Michael Horowitz
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
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: git p4: in-place submit
2012-05-02 17:06 ` Gary Gibbons
@ 2012-05-02 22:19 ` Pete Wyckoff
0 siblings, 0 replies; 6+ messages in thread
From: Pete Wyckoff @ 2012-05-02 22:19 UTC (permalink / raw)
To: Gary Gibbons; +Cc: Luke Diamand, git, Vitor Antunes, Michael Horowitz
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
>
^ permalink raw reply [flat|nested] 6+ messages in thread
end of thread, other threads:[~2012-05-02 22:19 UTC | newest]
Thread overview: 6+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2012-04-30 22:58 git p4: in-place submit Pete Wyckoff
2012-05-01 5:28 ` Luke Diamand
2012-05-01 22:18 ` Pete Wyckoff
2012-05-02 17:06 ` Gary Gibbons
2012-05-02 22:19 ` Pete Wyckoff
2012-05-01 19:27 ` Gary Gibbons
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).