Re: Announcing a new (prototype) git-remote-hg tool

From: Jeff King <peff@peff.net>
Date: Dec 6, 2014, 05:06 UTC
Message-ID: <20141206050628.GB31301@peff.net>
In-Reply-To: <20141205231330.GL16345@google.com>

On Fri, Dec 05, 2014 at 03:13:30PM -0800, Jonathan Nieder wrote:

Show 9 quoted lines

> > It's a shame that both squat on the name "remote-hg", because it makes
> > it difficult to tell the two apart. But of course that is the only way
> > to make "git clone hg::..." work. Maybe we need a layer of indirection?
> > :)
> 
> If the helpers are roughly interchangeable (that is, if you can switch
> between fetching using each one into the same on-disk git repository),
> then picking one to symlink as git-remote-hg in your $PATH should be
> enough.

That may be enough. For the most part you do not need to agree with other members of the project on which implementation to use. My experience with import tools has been that either:

  1. you are using them personally (because you do not like the
     upstream's choice of VCS and would prefer to transparently work in
     your favorite tool), or

  2. there is a group of developers who want to use git, but
     somebody provides an unofficial git mirror. They do not have to
     agree on the tool, because they just use git directly from the
     mirror.

So it is mostly a personal choice. But the two confusions I'd still anticipate are:

  a. It's difficult to even _talk_ about the tools, because the names
     are the same (so searching for tips on the tool, reporting bugs,
     etc, are harder than necessary).

  b. You may want different tools for different projects. If one tool is
     much more efficient, you may need it for a large repo (e.g.,
     mozilla). But another tool may provide other features, and you
     would prefer it for smaller repos.

This is largely speculation, though, and I do not actively use the tools myself. So I'd be happy to push off dealing with it until it itches enough for somebody to scratch.

-Peff