From: Pete Wyckoff <pw@padd.com>
To: git@vger.kernel.org
Cc: Luke Diamand <luke@diamand.org>,
Vitor Antunes <vitor.hda@gmail.com>,
Michael Horowitz <michael.horowitz@ieee.org>,
Gary Gibbons <ggibbons@perforce.com>
Subject: git p4: in-place submit
Date: Mon, 30 Apr 2012 18:58:48 -0400 [thread overview]
Message-ID: <20120430225848.GA2727@padd.com> (raw)
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
next reply other threads:[~2012-04-30 22:58 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-04-30 22:58 Pete Wyckoff [this message]
2012-05-01 5:28 ` git p4: in-place submit 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
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20120430225848.GA2727@padd.com \
--to=pw@padd.com \
--cc=ggibbons@perforce.com \
--cc=git@vger.kernel.org \
--cc=luke@diamand.org \
--cc=michael.horowitz@ieee.org \
--cc=vitor.hda@gmail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.