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 -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html