git.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
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/

  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).