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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.