Re: Announcing a new (prototype) git-remote-hg tool

From: Jonathan Nieder <jrnieder@gmail.com>
Date: Dec 5, 2014, 22:13 UTC
Message-ID: <20141205221319.GK16345@google.com>
In-Reply-To: <20141205205335.GA28935@glandium.org>

Mike Hommey wrote:

Show 9 quoted lines

> I'm currently evaluating what the final tool would look like. I'm *very*
> tempted to implement it in C, based on core git code, because there are
> many things that this helper does that would be so much easier to do
> with direct access to git's guts. And that wouldn't require more
> dependencies than git currently has: it would "just" need curl and ssh,
> and git already uses both.
>
> If I were to go in that direction, would you consider integrating it
> in git core?

Yes --- I would like this a lot.

The general trend has been to carry fewer contrib-style tools in-tree, since the problem of discovering tools built on top of git is not as hard as it used to be. What you describe above seems to be a bit of an exception:

 - libgit.a in its current state evolves too quickly for it to be
   convenient for out-of-tree tools to use.  cgit <http://git.zx2c4.com/cgit/>
   uses git pinned to a particular version as a submodule to get around
   this, which is fussy and has bad implications for remembering to
   get security updates.

 - an in-tree user of libgit.a would be useful as a reference example
   to use to try to make libgit.a into be a better library internally
   (and eventually expose e.g. by merging with libgit2 as something
   outside tools can link to, I hope)

 - if it makes sense to help people using the current remote helper
   in contrib to migrate to this, it could be convenient for users

In other words, although in the long term I would be happiest if libgit becomes good enough to let this project live in a separate tree and link to it, it's tempting to build this in-tree because we're not there yet.

Some other alternatives:

 - using libgit2 <https://libgit2.github.com/>

 - improving git plumbing (e.g., with new fast-import commands) or
   exposing a small library with a stable API for the tool's use

I haven't thought it through carefully but at the moment I like the in-tree approach best.

Thanks, Jonathan