threads / rfc / 8612

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

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

## tl;dr

7 messages between Jun 15, 2007 and Jun 22, 2007. Diffs are folded; open one to read it.

replies: 6people: 4as markdown or json

Kevin Green· Jun 15, 2007, 15:03 UTC · lore
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 <Kevin.Green@morganstanley.com>
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 <Kevin.Green@morganstanley.com>
---
 connect.c |    6 ++++++
 1 files changed, 6 insertions(+), 0 deletions(-)
Show changes to connect.c +6 −1
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
Julian Phillips· Jun 15, 2007, 15:30 UTC · re: Kevin Green · lore

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

On Fri, 15 Jun 2007, Kevin Green wrote:
Show 7 quoted lines
>
> 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
Kevin Green· Jun 15, 2007, 15:40 UTC · re: Julian Phillips · lore

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

On 06/15/07 11:30:12, Julian Phillips wrote:
Show 25 quoted lines
> 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.
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
Raimund Bauer· Jun 15, 2007, 15:54 UTC · re: Kevin Green · lore

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

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
Johannes Schindelin· Jun 19, 2007, 00:16 UTC · re: Kevin Green · lore

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

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

Kevin Green· Jun 22, 2007, 01:30 UTC · re: Johannes Schindelin · lore

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

On 06/18/07 20:16:47, Johannes Schindelin wrote:
Show 14 quoted lines
> 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.
>

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
Johannes Schindelin· Jun 22, 2007, 10:47 UTC · re: Kevin Green · lore

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

Hi,
On Thu, 21 Jun 2007, Kevin Green wrote:
Show 19 quoted lines
> On 06/18/07 20:16:47, Johannes Schindelin wrote:
> > 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.
> > 
> 
> 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

← back to recent threads