Skip to content
This repository has been archived by the owner on Mar 5, 2021. It is now read-only.

Finish git integration with credential repos #3

Open
nonspecialist opened this issue May 12, 2014 · 3 comments
Open

Finish git integration with credential repos #3

nonspecialist opened this issue May 12, 2014 · 3 comments

Comments

@nonspecialist
Copy link
Collaborator

No description provided.

@nonspecialist
Copy link
Collaborator Author

@nonspecialist
Copy link
Collaborator Author

This is complicated, at the moment, due to the fact that git2go (the primary golang binding for libgit2) is tracking the alpha, development branch of libgit2.

This leaves us at a decision point, at least for the near future: we can track git2go and libgit2 (which should be possible given that the distributable artifact is a mostly-static binary, but complicates the build environment considerably) or we can cheat and shell out to execute local git binaries (which makes the build environment trivially simple at the expense of reducing security and trustworthiness of the distributed binary, and increasing the complexity of the runtime environment)

My preference is to see just how hard it's going to be to temporarily complicate the build environment, and keep distributing a runtime that's a dependency-free and trustworthy as possible.

@nonspecialist
Copy link
Collaborator Author

I'm having a horrible time getting git2go integrated. I can build the latest libgit2, and generate a static library, and even build a mostly-static binary on Fedora/CentOS/RHEL -- but ubuntu doesn't ship static libraries for most things, which leaves it depending on various shared libraries at runtime.

I haven't even started looking at OSX (which I expect to be even more of a nightmare).

So the decision now seems to be:

  • build against shared libraries, and accept that there will be runtime linking that has to happen (this may not be so bad since packaging can take care of bringing in required libraries)
  • shell out, and trust $PATH and things like that (only mentioned for completeness)
  • build half the known universe as static libraries to link against
  • find some other git implementation that's pure Go, which supports remote repositories (do you know of one? I don't)

The decision seems clear to me -- suck it up and accept dynamic linking. We produce packages for Linux anyhow, and will be for OSX shortly too, so I don't think it's a showstopper.

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
Development

No branches or pull requests

1 participant