From mboxrd@z Thu Jan 1 00:00:00 1970 From: Jon Seymour Subject: Re: RFC: a plugin architecture for git extensions? Date: Sun, 8 May 2011 17:42:23 +1000 Message-ID: References: <7vhb986chl.fsf@alter.siamese.dyndns.org> <7vbozg4eqw.fsf@alter.siamese.dyndns.org> <20110506065601.GB13351@elie> <20110506141719.GA2991@elie> <20110506145036.GB2991@elie> <20110508064902.GA12868@elie> Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: QUOTED-PRINTABLE Cc: Junio C Hamano , David Aguilar , Andreas Ericsson , Joey Hess , Git Mailing List , "david@lang.hm" , Pau Garcia i Quiles To: Jonathan Nieder X-From: git-owner@vger.kernel.org Sun May 08 09:42:31 2011 Return-path: Envelope-to: gcvg-git-2@lo.gmane.org Received: from vger.kernel.org ([209.132.180.67]) by lo.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1QIydK-0007NS-LF for gcvg-git-2@lo.gmane.org; Sun, 08 May 2011 09:42:31 +0200 Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751412Ab1EHHmZ convert rfc822-to-quoted-printable (ORCPT ); Sun, 8 May 2011 03:42:25 -0400 Received: from mail-vx0-f174.google.com ([209.85.220.174]:35274 "EHLO mail-vx0-f174.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750911Ab1EHHmY convert rfc822-to-8bit (ORCPT ); Sun, 8 May 2011 03:42:24 -0400 Received: by vxi39 with SMTP id 39so4760358vxi.19 for ; Sun, 08 May 2011 00:42:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=M4Ub5z1ddvA+hYEx+oEbqABcsvkxmHHZUChu/n1DJnQ=; b=DcE0voQ0sjoKfC7OKPyrawS4atNoOXkYBwnVXEa63HaJesqrIYWiPOAEQmjMOXiaUI M+fja8mhojHL04ybVmDK/yaSGNMsz0wUr7DDEocGlIQrLzpPgeejUhL515GiDaXTVAoL VI6KRb/YUj60RuvfGZPk708eVQ5oKvLYDIWiA= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=HUOIj74kaMgLJdt8JibU5rujvn1wH5pcNGamMGib8GF8yNH01tekESbseeJBhcbmlU ZQ5VGj/0uTYv7SBQ8OC9nByx68qRh0gJH8P+aH2XveihS4+SVKSZOSqeGFT/b97AdsNo dLNsnRKPLRVTZ1RXBA3a/OHnQ8zi4pz6jO8v8= Received: by 10.52.169.135 with SMTP id ae7mr1922189vdc.79.1304840543524; Sun, 08 May 2011 00:42:23 -0700 (PDT) Received: by 10.52.160.66 with HTTP; Sun, 8 May 2011 00:42:23 -0700 (PDT) In-Reply-To: <20110508064902.GA12868@elie> Sender: git-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: git@vger.kernel.org Archived-At: On Sun, May 8, 2011 at 4:49 PM, Jonathan Nieder wr= ote: > Jon Seymour wrote: > >> The idea isn't to replace standard operating system facilities for >> application installation. The idea is to provide a uniform interface >> for accomplishing the rather limited task of extending git that can >> work the same way, irrespective of platform, irrespective of file >> system layouts, irrespective of assumptions about which directories >> are already in the user's paths. > [...] >> If at the end of the day, we say make and install are the way to do >> it, then fine. However, this makes the dependencies for a successful >> install strictly greater than the existence of git and a POSIX shell >> which we can assume if git is already installed. > > Thanks for explaining, and sorry to have given so much grief by not > understanding. > > If this whole conversation were about how to add a new menu item to > git gui, I would have understood completely. =C2=A0Having to figure o= ut how > to get something in a directory listed in PATH would be undue > complication. > > After going in circles a few times, I think you're saying there are > also some people using git on the command line for whom "make > prefix=3D install" won't cut it. =C2=A0With such a person = in mind, > what you're trying to do makes sense --- and why not do it, when it > will bring some other benefits as a side-effect, like the ability to > add new commands without them showing up in git- tab completion? > So I'll be quiet now. > Admittedly, I think there might be concrete advantages in making at hard as possible for such users to get anywhere near a git command line, but hey, I work in an environment where ClearCase looks like a reasonable option to some people :-) Your point about support for extension supplied HTML is an interesting one, that I don't think I have an answer for other than an installation script that is aware of git --html-path. The reason is, you want links to descriptions of core git commands to just work in such html, and the only way you can get that to happen reliably is to install in some directory that is strictly relative to the location that git's own HTML is stored in. So, in the end, I think I would be happy with a solution like: git --system-extensions-prefix which answers the recommended prefix for the installation of extensions. This might default git's own prefix, but may be configured differently by distribution or builder preference. If we did allow it to be different to the git prefix, then I think the git runtime would need to be extended to allow $(git --system-plugins-prefix)/bin to appear in the path, and then use the existing gt help mechanisms to find the man pages. Would a patch along these lines be acceptable, do you think? jon seymour.