git.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Andreas Ericsson <ae@op5.se>
To: git@vger.kernel.org
Subject: Re: [ANNOUNCE] GIT 0.99.9g
Date: Sat, 12 Nov 2005 13:17:14 +0100	[thread overview]
Message-ID: <4375DD4A.5050103@op5.se> (raw)
In-Reply-To: <7v64qzni9c.fsf@assigned-by-dhcp.cox.net>

Junio C Hamano wrote:
> 
>>>Oh, and we will not be moving things out of /usr/bin/ during 1.0
>>>timeframe.
>>
>>:(  bummer.  I do like the elegance of having /usr/bin/git executing 
>>stuff out of /usr/libexec/git.
> 
> 
> Bummer here as well.  This is not my first preference, but more
> or less "all things considered...".  I can go over cogito and
> stgit with Pasky and Catalin and coordinate the transition, but
> at the same time, everybody's existing scripts need to be
> adjusted.  As Linus said, we broke kernel.org snapshot scripts
> number of times.
> 
> Also places we execute git-upload-pack and git-receive-pack over
> an SSH connection need to be updated to execute 'git' with the
> first parameter 'upload-pack' and 'receive-pack' to make sure it
> would keep working with older or newer git on the other end.
> 

I've cooked up a patch that takes care of this if;
	git daemon
is executed (rather than git-daemon). Otherwise we could just mention in 
the docs that git-daemon must be run with the --libdir parameter (or 
whatever we decide to call it). If it prepends the libdir to the path 
everything will work same as always in the rest of the code so it'll be 
a very small change.

> After all that happens, we can start installing things in
> /usr/lib/git/.  During the transition, the C rewrite of git
> wrapper posted by Andreas Ericsson might help, so I am planning
> to merge it before 1.0,> after deciding what the right word for
> the "path to the rest of git executables" should be.
> 

All I really need to finalize it is that name, so It's up to you how 
fast you want it. Perhaps we could take a poll?

The suggestions so far come from the threads "git binary directory?" and 
"[PATCH] C implementation of the 'git' program" and some I just thought 
up. And here are the nominees;

	libdir
	path
	exec-path


Kay Sievers pointed out that libexec is not "LSB conformant" so it might 
be going away and is thus not listed.

exec-path was the last suggested name I got from Junio.

The form will be
	exec_path=$(prefix)/lib/git-@@VERSION@@
	GIT_EXEC_PATH
	--exec-path

for Makefile, environment and 'git', respectively. Substitute the 
obvious part with whatever you prefer.

> So let's say 1.0 will ship with all things in /usr/bin/, with
> updated docs that explain the situation: (1) the dash form
> 'git-frotz' is being deprecated, and you are encouraged to spell
> it as 'git frotz'; (2) if you want to use the dash form in your
> scripts for performance reasons, you need to have something like
> PATH="$(git --exec-path):$PATH" at the beginning of your script.
> 
> And after some time (say 2 months) we can switch.
> 

Sounds sensible, although I'm implementing Linus' idea of prepending the 
GIT_EXEC_PATH to $PATH so the porcelainish scripts in git-core shouldn't 
have to do it. If someone executes git-<script> from command-line I 
think it's safe to assume that they've added the exec-path to $PATH 
themselves. Someone *might* run

	/usr/lib/git-$GIT_VERSION/git-<script>

which should be cautioned against in the documentation.

-- 
Andreas Ericsson                   andreas.ericsson@op5.se
OP5 AB                             www.op5.se
Tel: +46 8-230225                  Fax: +46 8-230231

  reply	other threads:[~2005-11-12 12:17 UTC|newest]

Thread overview: 29+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2005-11-10  8:14 [ANNOUNCE] GIT 0.99.9g Junio C Hamano
2005-11-10  9:09 ` Jeff Garzik
2005-11-10 17:13   ` H. Peter Anvin
2005-11-10 18:34     ` Andreas Ericsson
2005-11-11 21:17       ` H. Peter Anvin
2005-11-12 11:37         ` Andreas Ericsson
2005-11-11 18:37   ` Junio C Hamano
2005-11-12 12:17     ` Andreas Ericsson [this message]
2005-11-14  7:46       ` Junio C Hamano
2005-11-14  9:23         ` Andreas Ericsson
2005-11-14 21:15           ` Junio C Hamano
2005-11-14  9:32         ` Petr Baudis
2005-11-10  9:54 ` Yaacov Akiba Slama
2005-11-10 19:55   ` Junio C Hamano
2005-11-10 17:09 ` H. Peter Anvin
2005-11-10 17:44   ` Junio C Hamano
2005-11-10 18:03     ` Petr Baudis
2005-11-10 18:31       ` Daniel Barkalow
2005-11-10 19:04         ` Junio C Hamano
2005-11-10 19:09           ` Daniel Barkalow
2005-11-10 19:32     ` Linus Torvalds
2005-11-10 19:43       ` Linus Torvalds
2005-11-11 21:18     ` H. Peter Anvin
2005-11-11 14:19   ` Johannes Schindelin
2005-11-11 17:46     ` H. Peter Anvin
2005-11-10 18:54 ` Jim Radford
2005-11-10 20:30   ` Andreas Ericsson
2005-11-10 20:48     ` Junio C Hamano
2005-11-11 18:23       ` Jim Radford

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=4375DD4A.5050103@op5.se \
    --to=ae@op5.se \
    --cc=git@vger.kernel.org \
    /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).