Re: [ANNOUNCE] GIT 0.99.9g

> 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
> 

> 
> 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.
>