Re: [PATCH 0/4] Writing refs in git-ssh-push

On Mon, 6 Jun 2005, Linus Torvalds wrote:

> Two comments on git-ssh-push from a quick try-to-use-it-but-fail..
> 
>  - hardcoding the name of the command on the other side kind of sucks. 
>    Especially when the user may end up having to install his own version
>    under his own subdirectory. You really want to have some way of saying 
>    "execute /home/user/bin/git-ssh-pull", and since it will depend on the 
>    site you're pushing to, it should probably be available as a cmd line 
>    option.
> 
>    I have a
> 
> 	PATH=$PATH:~/bin
> 
>    in my .bashrc, but sshd at the other end doesn't end up caring..

sshd is pretty odd that way; I think ~/.ssh/environment might get you your
local path. I thought it was just my sshd that was strange like that, but
it's probably common if yours does it too. I'm not sure if there's a
standard way to pick up a per-user version of the remote program. It seems
like cvs doesn't do anything clever, and sftp makes it a compile-time
option.

I think an environment variable for the directory to find
git-ssh-(other) in would be easiest to script when needed and would also
reduce the chances of specifying the wrong program on the remote side
(which would generate really confusing errors).

>  - the host/path parsing is pretty simplistic and just silly. Nobody I 
>    know uses that ssh://host/path format, people use the shorter host:path 
>    format.

I was going for uniformity between git-http-pull and git-ssh-pull, and
between git-ssh-pull and git-ssh-push. But user@host:path is probably the
right thing, although Radoslaw (cc:ed) will want to propose something for
SSH on a non-standard port.

> Both look pretty simple to fix, but now I'm going to put the kids to bed.

Yeah, they're usability issues, and I'm too willing to put up with my own
programs being awkward.

	-Daniel
*This .sig left intentionally blank*

-
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