From: Junio C Hamano <junkio@cox.net>
To: Andreas Ericsson <ae@op5.se>
Cc: git@vger.kernel.org
Subject: Re: [ANNOUNCE] GIT 0.99.9g
Date: Mon, 14 Nov 2005 13:15:31 -0800 [thread overview]
Message-ID: <7vwtjbvslo.fsf@assigned-by-dhcp.cox.net> (raw)
In-Reply-To: <4378578E.5090409@op5.se> (Andreas Ericsson's message of "Mon, 14 Nov 2005 10:23:26 +0100")
Andreas Ericsson <ae@op5.se> writes:
> Junio C Hamano wrote:
>> 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.
Yes, but the problem is when that "someday" comes. Unlike a
single machine installation where we can tell "git" to look into
somewhere different at the same time we move the subcommands out
of /usr/bin, "the other end" can lag behind and sometimes not
under control of the end user.
I think it's simpler to manage and can be made configuration
free if we keep receive-pack and upload-pack in /usr/bin and
always call these programs in dash-form (i.e. not "git
upload-pack") from the other end. .bash_profile is not read for
incoming ssh connections to execute a single command, but many
people set their PATH in there, without setting PATH in .bashrc.
I personally think that having to set PATH in .bashrc it is
actually a bug in what bash does, but that is OT.
next prev parent reply other threads:[~2005-11-14 21:15 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
2005-11-14 21:15 ` Junio C Hamano [this message]
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=7vwtjbvslo.fsf@assigned-by-dhcp.cox.net \
--to=junkio@cox.net \
--cc=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).