git.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Jonathan Nieder <jrnieder@gmail.com>
To: Mike Hommey <mh@glandium.org>
Cc: git@vger.kernel.org, Junio C Hamano <gitster@pobox.com>
Subject: Re: Announcing a new (prototype) git-remote-hg tool
Date: Fri, 5 Dec 2014 14:13:19 -0800	[thread overview]
Message-ID: <20141205221319.GK16345@google.com> (raw)
In-Reply-To: <20141205205335.GA28935@glandium.org>

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

  reply	other threads:[~2014-12-05 22:13 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-12-05 20:53 Announcing a new (prototype) git-remote-hg tool Mike Hommey
2014-12-05 22:13 ` Jonathan Nieder [this message]
2014-12-05 22:59   ` Jeff King
2014-12-05 23:13     ` Jonathan Nieder
2014-12-05 23:46       ` Mike Hommey
2014-12-06  5:06       ` Jeff King
2014-12-05 23:31     ` Mike Hommey
2014-12-05 22:44 ` Philip Oakley
2015-02-11  9:32 ` Announcing git-cinnabar 0.1.0 (Was: Announcing a new (prototype) git-remote-hg tool) Mike Hommey

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20141205221319.GK16345@google.com \
    --to=jrnieder@gmail.com \
    --cc=git@vger.kernel.org \
    --cc=gitster@pobox.com \
    --cc=mh@glandium.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).