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: Mon, 14 Nov 2005 10:23:26 +0100	[thread overview]
Message-ID: <4378578E.5090409@op5.se> (raw)
In-Reply-To: <7vwtjb3c4i.fsf@assigned-by-dhcp.cox.net>

Junio C Hamano wrote:
> Andreas Ericsson <ae@op5.se> writes:
> 
> 
>>>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)...
> 
> 
> Actually I was more worried about these git native protocols
> going over ssh, which is not helped by git-daemon.  I think
> teaching the libdir to git-shell would make sense for "git
> restricted shell" users, but most users coming from ssh to run
> git native protocols would need to have some way of running the
> executable on the other end.
> 
> My current thinking about this problem is that the handful
> programs that need to run "on the other end" should stay in
> /usr/bin, even after we move most things out of /usr/bin, if
> only to avoid configuration hassles.  They are:
> 
> 	receive-pack, upload-pack
>         ssh-fetch, ssh-pull, ssh-push, ssh-upload
> 

I liked your suggestion of deprecating the /usr/bin use a month or two 
before it's effected better. We could then provide symlinks for the 
necessary programs that point to their real locations in GIT_EXEC_PATH 
and (someday) drop those links when they're no longer needed.

> 
> Somehow libdir reminds me of where libraries are installed by
> the Makefile, which usually does not mean executables, and that
> was the reason I mentioned --exec-path.  Although I do not have
> strong preference myself either way, I do not think the list
> cares too much either, so in order not to waste time by
> indecision, let's just say we use this one:
> 
> 
>>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.
> 
> 
>>..., 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.
> 
> 
> This sounds good to me; let's go with it.  Thanks.
> 

I'll get busy then.

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

  reply	other threads:[~2005-11-14  9:24 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
2005-11-14  7:46       ` Junio C Hamano
2005-11-14  9:23         ` Andreas Ericsson [this message]
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=4378578E.5090409@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).