git.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Tor Arvid Lund <torarvid@gmail.com>
To: Daniel Barkalow <barkalow@iabervon.org>
Cc: git@vger.kernel.org
Subject: Re: [PATCH not-for-mainline] Implement git-vcs-p4
Date: Wed, 27 Jan 2010 12:18:35 +0100	[thread overview]
Message-ID: <1a6be5fa1001270318h4ac8ac3bnaba48787a5b3efa6@mail.gmail.com> (raw)
In-Reply-To: <alpine.LNX.2.00.1001251628431.14365@iabervon.org>

On Mon, Jan 25, 2010 at 10:35 PM, Daniel Barkalow <barkalow@iabervon.org> wrote:
> This is probably not particularly appropriate for mainline
> application, and is somewhat buggy, not extensively tested, and
> incomplete. The push support is also currently based on a transport helper
> export design that isn't upstream and I don't like any more; a better
> design is probably to have the core send an "export" command and then a
> gfi stream, but I haven't worked on this.
>
> It has two implementations of the interaction with the Perforce
> server: one that uses the command-line client (and therefore makes a
> ton of separate connections to the server) and one that uses the
> (closed source, vaguely licensed) C++ API. The former does not support
> everything used in push/submit correctly at this point.
>
> It also adds support to the Makefile for building C++ object files and
> linking with a C++ linker. It should be easy to omit entirely for
> builds that don't use p4, and it's at least somewhat out of the way.
>
> The biggest flaw currently is that it doesn't save its analysis of the
> structure of the history, and doesn't have a way to push it out of memory,
> so a long or complex history will run you out of memory or will take a
> long time to do an incremental fetch.
>
> Fetch features:
>
>  - following integrations (with some guessing)
>  - finding other branches of a codeline
>
> Push features (only with the C++ API):
>
>  - works if you don't do anything at all complicated
>
> Signed-off-by: Daniel Barkalow <barkalow@iabervon.org>
<snip>

Hi, and thank you for posting this.

I tried applying it to current master, and got it to compile using the
p4 c++ api.

However, I'm having trouble getting it to run. This is most certainly
my own fault, and I'm guessing it has to do with my .git/config file
setup.

I tried doing 'git init', and making a .git/config file like so:
------------
[core]
        repositoryformatversion = 0
        filemode = true
        bare = false
        logallrefupdates = true

[vcs-p4]
        port = perforce.mycompany.com:1666
        client = toral

[remote "origin"]
        vcs = p4
        codeline = //depot/path/to/my/existing/test/project
------------
Then, I did 'git fetch', and got a seg fault. I got around it by
commenting out a line:

diff --git a/transport.c b/transport.c
index 7714fdb..5b404f7 100644
--- a/transport.c
+++ b/transport.c
@@ -924,7 +924,7 @@ struct transport *transport_get(struct remote
*remote, const char *url)
        ret->url = url;

        /* In case previous URL had helper forced, reset it. */
-       remote->foreign_vcs = NULL;
+/*     remote->foreign_vcs = NULL;*/

        /* maybe it is a foreign URL? */
        if (url) {

-------------
So - now I get this:

$ GIT_TRANSPORT_HELPER_DEBUG=1 git fetch
Debug: Remote helper: -> capabilities
Debug: Remote helper: Waiting...
Debug: Remote helper: <- import
Debug: Got cap import
Debug: Remote helper: Waiting...
Debug: Remote helper: <- export
Debug: Got cap export
Debug: Remote helper: Waiting...
Debug: Remote helper: <-
Debug: Capabilities complete.
Debug: Remote helper: Waiting...
Debug: Remote helper: <- ? refs/p4/depot/path/to/my/existing/test/project
Debug: Remote helper: Waiting...
Debug: Remote helper: <- ? refs/p4/depot/path/to/my/existing/test/project
Debug: Remote helper: Waiting...
Debug: Remote helper: <-
Debug: Read ref listing.
fatal: Couldn't find remote ref HEAD
-------------

I also tried setting vcs-p4.findbranches to 'true'. The only
difference in the output, is that the "<- ? refs/p4/..." line is just
output once.

So if anyone has a clue for me, I shall, well, cease to be clueless.

-Tor Arvid-

  parent reply	other threads:[~2010-01-27 11:18 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-01-25 21:35 [PATCH not-for-mainline] Implement git-vcs-p4 Daniel Barkalow
2010-01-25 21:53 ` Sverre Rabbelier
2010-01-25 22:26   ` Daniel Barkalow
2010-01-25 22:28     ` Sverre Rabbelier
2010-01-27 11:18 ` Tor Arvid Lund [this message]
2010-01-27 15:56   ` Ilari Liusvaara
2010-01-27 16:49     ` Daniel Barkalow
2010-01-27 17:14       ` Ilari Liusvaara
2010-01-27 17:28         ` Daniel Barkalow
2010-01-27 17:49           ` Ilari Liusvaara
2010-01-27 17:18   ` Daniel Barkalow

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=1a6be5fa1001270318h4ac8ac3bnaba48787a5b3efa6@mail.gmail.com \
    --to=torarvid@gmail.com \
    --cc=barkalow@iabervon.org \
    --cc=git@vger.kernel.org \
    /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).