From: John Keeping <john@keeping.me.uk>
To: Junio C Hamano <gitster@pobox.com>
Cc: git@vger.kernel.org, Michael Haggerty <mhagger@alum.mit.edu>
Subject: Re: What's cooking in git.git (Apr 2014, #09; Tue, 29)
Date: Wed, 7 May 2014 09:05:58 +0100 [thread overview]
Message-ID: <20140507080558.GH23935@serenity.lan> (raw)
In-Reply-To: <xmqqd2fqcv7s.fsf@gitster.dls.corp.google.com>
On Tue, May 06, 2014 at 05:01:59PM -0700, Junio C Hamano wrote:
> 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.
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/
next prev parent reply other threads:[~2014-05-07 8:06 UTC|newest]
Thread overview: 35+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-04-29 22:38 What's cooking in git.git (Apr 2014, #09; Tue, 29) Junio C Hamano
2014-05-05 18:45 ` John Keeping
2014-05-05 19:08 ` Felipe Contreras
2014-05-05 19:55 ` John Keeping
2014-05-05 20:34 ` Felipe Contreras
2014-05-05 21:43 ` Felipe Contreras
2014-05-06 17:59 ` Junio C Hamano
2014-05-06 18:54 ` Felipe Contreras
2014-05-05 23:50 ` Junio C Hamano
2014-05-06 0:20 ` Felipe Contreras
2014-05-06 0:39 ` Felipe Contreras
2014-05-06 8:07 ` John Keeping
2014-05-06 8:32 ` Felipe Contreras
2014-05-06 19:34 ` Junio C Hamano
2014-05-06 19:39 ` Felipe Contreras
2014-05-07 11:44 ` Greg Troxel
2014-05-07 19:54 ` Felipe Contreras
2014-05-07 23:38 ` Greg Troxel
2014-05-08 0:18 ` Felipe Contreras
2014-05-08 7:29 ` Chris Packham
2014-05-08 7:56 ` Felipe Contreras
2014-05-09 0:40 ` David Lang
2014-05-09 0:58 ` Felipe Contreras
2014-05-09 0:58 ` Submodule improvements (Re: What's cooking in git.git (Apr 2014, #09; Tue, 29)) Jonathan Nieder
2014-05-08 18:31 ` What's cooking in git.git (Apr 2014, #09; Tue, 29) Junio C Hamano
2014-05-07 0:01 ` Junio C Hamano
2014-05-07 0:17 ` Felipe Contreras
2014-05-07 8:05 ` John Keeping [this message]
2014-05-07 9:26 ` Felipe Contreras
2014-05-07 18:56 ` Junio C Hamano
2014-05-07 19:28 ` John Keeping
2014-05-07 19:50 ` Felipe Contreras
2014-05-07 20:26 ` Felipe Contreras
2014-05-07 20:44 ` John Keeping
2014-05-07 21:38 ` Felipe Contreras
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20140507080558.GH23935@serenity.lan \
--to=john@keeping.me.uk \
--cc=git@vger.kernel.org \
--cc=gitster@pobox.com \
--cc=mhagger@alum.mit.edu \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).