ggibbons@xxxxxxxxxxxx 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@xxxxxxxxxxx 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@xxxxxxxxxxxxxxx > More majordomo info at http://vger.kernel.org/majordomo-info.html > -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html