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

From: Jonathan Nieder <[email-masked]>
Date: Fri, 5 Dec 2014 14:13:19 -0800

Mike Hommey wrote:

> 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