John Keeping [off-list ref] 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.
Junio C Hamano wrote:
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.
Since Git's test framework heavily tied to git.git, sharness[1] is the
only sensible option. It might not have all the latest features of Git's
test framework, but it's standalone.
[1] https://github.com/mlafeldt/sharness
--
Felipe Contreras
On Tue, May 06, 2014 at 05:01:59PM -0700, Junio C Hamano wrote:
John Keeping [off-list ref] writes:
quoted
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.
This can already work given suitable installation. With
git-integration[1] I can type `git help integration` and it shows me the
man page in the same way that `git help commit` does. When I manually
linked the HTML file to the right place `git help -w integration` worked
as well.
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.
I think this is enough - now I need to go and make git-integration's
Makefile use them by default rather than just using the same defaults as
git.git.
Perhaps it would be useful to have a skeleton "external Git utility"
project under contrib/ which could demonstrate best practice for
installing utilties that augment Git.
[1] http://johnkeeping.github.io/git-integration/
John Keeping wrote:
quoted
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.
I think this is enough - now I need to go and make git-integration's
Makefile use them by default rather than just using the same defaults as
git.git.
This is wrong. Subprojects should use /usr/bin/ and /usr/share/man/ and
not rely on the output of `git --exec-path` and so on.
For example if the user has installed Git in his $home, when building a
package the package manager would use ~/libexec/git-core, which is
wrong.
Moreover, if you are cross-compiling you won't be able to run the
target's `git` binary.
If anything, it should be `pkg-config --variable=exec-path git`.
--
Felipe Contreras