Daniel Barkalow <barkalow@iabervon.org> wrote:
quoted text
> On Tue, 24 Jun 2008, Junio C Hamano wrote:
> 
> > Otherwise remote executions directly over ssh won't find them as they used
> > to.  --upload-pack and --receive-pack options _could_ be used on the
> > client side, but things should keep working out-of-box for older clients.
> > 
> > Later versions of clients (fetch-pack and send-pack) probably could start
> > asking for these programs with dashless form, but that is a different
> > topic.
> 
> Should they use "git upload-pack" or should they look for their helper 
> programs in a libexec dir? I don't think that either of these programs is 
> useful to run independantly, but I don't know if finding a program that 
> doesn't go in $PATH on a remote machine is going to be any fun.

IMHO they should in the future use "git upload-pack".

But this may not work with all servers, especially those that
use $SSH_ORIGINAL_COMMAND to dispatch to the correct command,
or abort if the user tries to request something dangerous.
Gitosis comes to mind.

I'm not sure we can get away with doing this in 1.6.0 as it is
effectively a network protocol breakage.  We have thus far never
caused a newer client to fail talking to an older server.  I'm
not sure we should start doing that in 1.6.0.

My vote is we keep the dashed form of these 3 commands in the
$PATH during 1.6 and remove them in 1.7, but when we do it we
must ensure there is a way to still request dashed form found
through $PATH when passing --upload-pack as an argument.

-- 
Shawn.
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html