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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.