[RFC][PATCH] Fix assumption that git is installed in a standard place on the remote end ssh

Hi,

I've run into a problem pushing/pulling where we don't (READ: can't) have git installed in the
standard location.  This leads to a failure on trying to find the git binaries
on the remote end.  I've looked through the archives and didn't come across
any similar discussions.  Please point me there if I've missed something...

I wanted to introduce a commandline arg, similar to what rsync does, call it
--git-path=PATH, where a user can specify the location of git on the remote
end. 

After tracking through what really is happening with a git pull, I realized
that a change like that is pretty intrusive and is not just a simple addition
to the ssh handling code, i.e. we'll need to push that arg through all the sh
scripts, etc...

I settled on allowing an env var to be exported, GIT_REMOTE_PATH which a user
can set to the path of git on the remote end.

I want to open up the discussion on whether this is the best way forward or if
there's another way I've missed.


Here's the patch that introduces this new feature:

--- cut here ---

Author: Kevin Green [off-list ref]
Date: Fri, 15 Jun 2007 10:51:21 -0400

Fix assumption that git is installed in a standard place on the remote end ssh

Introduce env var GIT_REMOTE_PATH which a user can set to the known remote path of
git during a push or pull through PROTO_SSH.

Signed-off-by: Kevin Green <redacted>
---
 connect.c |    6 ++++++
 1 files changed, 6 insertions(+), 0 deletions(-)

diff --git a/connect.c b/connect.c
index 7fab9c0..ee15a8a 100644
--- a/connect.c
+++ b/connect.c

@@ -560,7 +560,13 @@ pid_t git_connect(int fd[2], char *url, const char *prog, int flags)
                char *posn = command;
                int size = MAX_CMD_LEN;
                int of = 0;
+               const char *git_remote_path;

+               git_remote_path = getenv("GIT_REMOTE_PATH");
+               if (git_remote_path) {
+                       of |= add_to_string(&posn, &size, git_remote_path, 0);
+                       of |= add_to_string(&posn, &size, "/", 0);
+               }
                of |= add_to_string(&posn, &size, prog, 0);
                of |= add_to_string(&posn, &size, " ", 0);
                of |= add_to_string(&posn, &size, path, 1);
--

1.5.2.1

On Fri, 15 Jun 2007, Kevin Green wrote:

Hi,

I've run into a problem pushing/pulling where we don't (READ: can't) have git installed in the
standard location.  This leads to a failure on trying to find the git binaries
on the remote end.  I've looked through the archives and didn't come across
any similar discussions.  Please point me there if I've missed something...

from the git-pull manpage:

        --upload-pack <upload-pack>
               When given, and the repository to fetch from is handled by
               git-fetch-pack, --exec=<upload-pack> is passed to the command
               to specify non-default path for the command run on the other
               end.

and git-pull:

        --receive-pack=<git-receive-pack>
               Path to the git-receive-pack program on the remote end.
               Sometimes useful when pushing to a remote repository over ssh,
               and you do not have the program in a directory on the default
               $PATH.

-- 
Julian

  ---
To be or not to be.
 		-- Shakespeare
To do is to be.
 		-- Nietzsche
To be is to do.
 		-- Sartre
Do be do be do.
 		-- Sinatra

On 06/15/07 11:30:12, Julian Phillips wrote:

On Fri, 15 Jun 2007, Kevin Green wrote:

quoted

Hi,

I've run into a problem pushing/pulling where we don't (READ: can't) have git installed in the
standard location.  This leads to a failure on trying to find the git binaries
on the remote end.  I've looked through the archives and didn't come across
any similar discussions.  Please point me there if I've missed something...

from the git-pull manpage:

        --upload-pack <upload-pack>
               When given, and the repository to fetch from is handled by
               git-fetch-pack, --exec=<upload-pack> is passed to the command
               to specify non-default path for the command run on the other
               end.

and git-pull:

        --receive-pack=<git-receive-pack>
               Path to the git-receive-pack program on the remote end.
               Sometimes useful when pushing to a remote repository over ssh,
               and you do not have the program in a directory on the default
               $PATH.

Thanks!

I did completely miss this when I went through the manpage...

I'm thinking I like the env var idea much more though.  I can just export it
in my shell and it works in both cases.  I could of course alias the commands
so I don't have to keep typing it everytime, but that's more painful still...

--Kevin

On Fri, 2007-06-15 at 11:40 -0400, Kevin Green wrote:

I'm thinking I like the env var idea much more though.  I can just export it
in my shell and it works in both cases.  I could of course alias the commands
so I don't have to keep typing it everytime, but that's more painful still...

do 'git config --help' and check the options

remote.<name>.receivepack
remote.<name>.uploadpack

--Kevin

-- 
best regards

  Ray

Hi,

On Fri, 15 Jun 2007, Kevin Green wrote:

I'm thinking I like the env var idea much more though.  I can just 
export it in my shell and it works in both cases.

And it completely breaks down when you have more than one remotes. Or when 
you cd to another project with another remote. Or etc. IOW it is fragile.

Clearly, the config approach is the only one which makes sense. This 
information is so closely coupled to a specific remote that you should 
store it right where you store all the other remote information, too.

Ciao,
Dscho

On 06/18/07 20:16:47, Johannes Schindelin wrote:

Hi,

On Fri, 15 Jun 2007, Kevin Green wrote:

quoted

I'm thinking I like the env var idea much more though.  I can just 
export it in my shell and it works in both cases.

And it completely breaks down when you have more than one remotes. Or when 
you cd to another project with another remote. Or etc. IOW it is fragile.

Clearly, the config approach is the only one which makes sense. This 
information is so closely coupled to a specific remote that you should 
store it right where you store all the other remote information, too.

You're absolutely right.  I agree, except that in _my_ environment git will
be in a non-standard path but *always* consistently in the same place.  I'm being
greedy here. :)

The config approach is clearly the most versatile.  The question I have is, is
there a good reason not to provide the third option of setting env var?  I suppose that in the
more likely case this could cause more harm than good, i.e. maybe
this is too specific for my use case.


Thanks

--Kevin

Hi,

On Thu, 21 Jun 2007, Kevin Green wrote:

On 06/18/07 20:16:47, Johannes Schindelin wrote:

quoted

Hi,

On Fri, 15 Jun 2007, Kevin Green wrote:

quoted

I'm thinking I like the env var idea much more though.  I can just 
export it in my shell and it works in both cases.

And it completely breaks down when you have more than one remotes. Or when 
you cd to another project with another remote. Or etc. IOW it is fragile.

Clearly, the config approach is the only one which makes sense. This 
information is so closely coupled to a specific remote that you should 
store it right where you store all the other remote information, too.

You're absolutely right.  I agree, except that in _my_ environment git 
will be in a non-standard path but *always* consistently in the same 
place.  I'm being greedy here. :)

Note that this "solution" will _only_ work for you.

The config approach is clearly the most versatile.  The question I have 
is, is there a good reason not to provide the third option of setting 
env var?  I suppose that in the more likely case this could cause more 
harm than good, i.e. maybe this is too specific for my use case.

Since it will _only_ work for you, I think there is more harm done than 
good, by including that in mainline git. Just think of somebody seeing 
this mentioned in the docs, not reading further properly, and just getting 
confused, blaming it on Git.

Instead, we have that wonderful config solution, which is the proper one 
anyway, and which does not confuse people, once they found it.

However, Git is all about the freedom to fork and merge. So do the same as 
me: keep those changes in your local repo, and do not use mainline Git.

For example, I have this option "-t" to Git, which automatically tries to 
give human-readable names to all the 40-character object names, and does 
not change colouring. Thus, I can say

	git -t log -p whatever.c

to find exactly which commit introduced a certain feature (which I find by 
searching the diffs). Then, I only have to copy&paste the nice commit name 
into the mail/IRC where I am responding to, and be done.

This feature was not liked on the list, so it remains in my local fork 
forever (though it is also stored in the mail archives).

Ciao,
Dscho