Re: [PATCH not-for-mainline] Implement git-vcs-p4

From

Tor Arvid Lund <torarvid@gmail.com>

Date

Jan 27, 2010, 11:18 UTC

Message-ID

<1a6be5fa1001270318h4ac8ac3bnaba48787a5b3efa6@mail.gmail.com>

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