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

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