Re: What's cooking in git.git (Apr 2014, #09; Tue, 29)

> John Keeping <john@keeping.me.uk> 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.