From: Luke Diamand <luke@diamand.org>
To: Pete Wyckoff <pw@padd.com>
Cc: git@vger.kernel.org, Vitor Antunes <vitor.hda@gmail.com>,
Michael Horowitz <michael.horowitz@ieee.org>,
Gary Gibbons <ggibbons@perforce.com>
Subject: Re: git p4: in-place submit
Date: Tue, 01 May 2012 06:28:55 +0100 [thread overview]
Message-ID: <4F9F7497.5050504@diamand.org> (raw)
In-Reply-To: <20120430225848.GA2727@padd.com>
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.
next prev parent reply other threads:[~2012-05-01 5:29 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-04-30 22:58 git p4: in-place submit Pete Wyckoff
2012-05-01 5:28 ` Luke Diamand [this message]
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=4F9F7497.5050504@diamand.org \
--to=luke@diamand.org \
--cc=ggibbons@perforce.com \
--cc=git@vger.kernel.org \
--cc=michael.horowitz@ieee.org \
--cc=pw@padd.com \
--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 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).