All of lore.kernel.org
 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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.