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 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).