git.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
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.

  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).