John Keeping <john@xxxxxxxxxxxxx> writes:
> I'd like to register my opposition to moving git-remote-{bzr,hg} out of
> contrib/.
>
> I am not convinced that tools for interoperating with other VCSs need to
> be part of core Git; as Junio has pointed out previously, while contrib/
> was necessary ... Associated tools can
> therefore live on their own and do not need to be promoted as part of
> Git itself (as git-imerge is doing successfully).
Another thing to keep in mind is that we need to ensure that we give
a good way for these third-party tools to integrate well with the
core Git tools to form a single toolchest for the users. I would
love to be able to do
$ (cd git.git && make install)
$ (cd git-imerge.git && make install)
and then say "git imerge", "git --help imerge", etc. The same for
the remote helpers that we may be splitting out of my tree into
their own stand-alone projects.
I _think_ it probably is OK for git-imerge.git/Makefile to peek into
our Makefile, e.g.
$ cd git-imerge.git
$ make GIT_SOURCE_DIR=../git.git install
to learn where imerge should install its subcommand implementation
and documentation. It might even want to borrow the test framework
by using $GIT_SOURCE_DIR/t/test-lib.sh or somesuch. There may be
some changes the third-party tool authors would want to have in our
Makefile to help them better when building their tools this way; I
dunno.
I also think that there should be a way to make it really easy to
install these third-party tools to augment the installed version of
Git without having the source tree of Git. We have ways for them to
ask us where things are expected to be, e.g.
$ git --html-path
$ git --man-path
$ git --exec-path
but I am not sure if these are enough, or if it would help them to
add a bit more, then what these "a bit more" are.
--
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