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
next prev parent 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.