On Wed, 27 Jan 2010, Tor Arvid Lund wrote:
> On Mon, Jan 25, 2010 at 10:35 PM, Daniel Barkalow <barkalow@xxxxxxxxxxxx> 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@xxxxxxxxxxxx>
> <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.
The p4 remote helper doesn't present the remote as having a ref "HEAD". It
probably ought to when you've configured exactly one codeline, which is
obviously the default you mean. (And that should be an easy addition.)
The way I use it is to have a line like:
fetch = refs/p4/depot/path/to/my/existing/test/project:refs/remotes/origin/master
Or, actually, I'm making a mirror of the p4 (since I want multiple
working directories without redoing the import), so I'm fetching a pattern
into refs/heads/*.
The findBranches thing can identify more branches by looking at outgoing
integrations, but these (if any) come out with the same long branches
name, and need to be fetched into something sensible.
-Daniel
*This .sig left intentionally blank*