{"thread":{"id":"8612","subject":"[RFC][PATCH] Fix assumption that git is installed in a standard place on the remote end ssh","startedAt":"2007-06-15T15:03:51Z","lastAt":"2007-06-22T10:47:00Z","messageCount":7,"participants":["Kevin Green","Julian Phillips","Raimund Bauer","Johannes Schindelin"],"isPatch":true,"patchVersion":1,"patchTotal":null},"messages":[{"id":"45137","messageId":"20070615150351.GH14677@menevado.ms.com","threadId":"8612","inReplyTo":null,"subject":"[RFC][PATCH] Fix assumption that git is installed in a standard place on the remote end ssh","fromName":"Kevin Green","fromEmail":"kevin.t.green@morganstanley.com","sentAt":"2007-06-15T15:03:51Z","receivedAt":"2007-06-15T15:03:51Z","isPatch":true,"sender":{"key":"kevin.t.green@morganstanley.com","avatar":null},"body":"\nHi,\n\nI've run into a problem pushing/pulling where we don't (READ: can't) have git installed in the\nstandard location. This leads to a failure on trying to find the git binaries\non the remote end. I've looked through the archives and didn't come across\nany similar discussions. Please point me there if I've missed something...\n\nI wanted to introduce a commandline arg, similar to what rsync does, call it\n--git-path=PATH, where a user can specify the location of git on the remote\nend. \n\nAfter tracking through what really is happening with a git pull, I realized\nthat a change like that is pretty intrusive and is not just a simple addition\nto the ssh handling code, i.e. we'll need to push that arg through all the sh\nscripts, etc...\n\nI settled on allowing an env var to be exported, GIT_REMOTE_PATH which a user\ncan set to the path of git on the remote end.\n\nI want to open up the discussion on whether this is the best way forward or if\nthere's another way I've missed.\n\n\nHere's the patch that introduces this new feature:\n\n--- cut here ---\nAuthor: Kevin Green \nDate: Fri, 15 Jun 2007 10:51:21 -0400\n\nFix assumption that git is installed in a standard place on the remote end ssh\n\nIntroduce env var GIT_REMOTE_PATH which a user can set to the known remote path of\ngit during a push or pull through PROTO_SSH.\n\nSigned-off-by: Kevin Green \n---\n connect.c | 6 ++++++\n 1 files changed, 6 insertions(+), 0 deletions(-)\n\ndiff --git a/connect.c b/connect.c\nindex 7fab9c0..ee15a8a 100644\n--- a/connect.c\n+++ b/connect.c\n@@ -560,7 +560,13 @@ pid_t git_connect(int fd[2], char *url, const char *prog, int flags)\n char *posn = command;\n int size = MAX_CMD_LEN;\n int of = 0;\n+ const char *git_remote_path;\n\n+ git_remote_path = getenv(\"GIT_REMOTE_PATH\");\n+ if (git_remote_path) {\n+ of |= add_to_string(&posn, &size, git_remote_path, 0);\n+ of |= add_to_string(&posn, &size, \"/\", 0);\n+ }\n of |= add_to_string(&posn, &size, prog, 0);\n of |= add_to_string(&posn, &size, \" \", 0);\n of |= add_to_string(&posn, &size, path, 1);\n--\n1.5.2.1\n"},{"id":"45140","messageId":"Pine.LNX.4.64.0706151628180.31972@reaper.quantumfyre.co.uk","threadId":"8612","inReplyTo":"20070615150351.GH14677@menevado.ms.com","subject":"Re: [RFC][PATCH] Fix assumption that git is installed in a standard place on the remote end ssh","fromName":"Julian Phillips","fromEmail":"julian@quantumfyre.co.uk","sentAt":"2007-06-15T15:30:12Z","receivedAt":"2007-06-15T15:30:12Z","isPatch":true,"sender":{"key":"julian@quantumfyre.co.uk","avatar":"https://avatars.githubusercontent.com/u/948888?v=4"},"body":"On Fri, 15 Jun 2007, Kevin Green wrote:\n\n>\n> Hi,\n>\n> I've run into a problem pushing/pulling where we don't (READ: can't) have git installed in the\n> standard location. This leads to a failure on trying to find the git binaries\n> on the remote end. I've looked through the archives and didn't come across\n> any similar discussions. Please point me there if I've missed something...\n\nfrom the git-pull manpage:\n\n --upload-pack \n When given, and the repository to fetch from is handled by\n git-fetch-pack, --exec= is passed to the command\n to specify non-default path for the command run on the other\n end.\n\nand git-pull:\n\n --receive-pack=\n Path to the git-receive-pack program on the remote end.\n Sometimes useful when pushing to a remote repository over ssh,\n and you do not have the program in a directory on the default\n $PATH.\n\n-- \nJulian\n\n ---\nTo be or not to be.\n \t\t-- Shakespeare\nTo do is to be.\n \t\t-- Nietzsche\nTo be is to do.\n \t\t-- Sartre\nDo be do be do.\n \t\t-- Sinatra\n"},{"id":"45141","messageId":"20070615154000.GK14677@menevado.ms.com","threadId":"8612","inReplyTo":"Pine.LNX.4.64.0706151628180.31972@reaper.quantumfyre.co.uk","subject":"Re: [RFC][PATCH] Fix assumption that git is installed in a standard place on the remote end ssh","fromName":"Kevin Green","fromEmail":"kevin.t.green@morganstanley.com","sentAt":"2007-06-15T15:40:00Z","receivedAt":"2007-06-15T15:40:00Z","isPatch":true,"sender":{"key":"kevin.t.green@morganstanley.com","avatar":null},"body":"On 06/15/07 11:30:12, Julian Phillips wrote:\n> On Fri, 15 Jun 2007, Kevin Green wrote:\n> \n> >\n> > Hi,\n> >\n> > I've run into a problem pushing/pulling where we don't (READ: can't) have git installed in the\n> > standard location. This leads to a failure on trying to find the git binaries\n> > on the remote end. I've looked through the archives and didn't come across\n> > any similar discussions. Please point me there if I've missed something...\n> \n> from the git-pull manpage:\n> \n> --upload-pack \n> When given, and the repository to fetch from is handled by\n> git-fetch-pack, --exec= is passed to the command\n> to specify non-default path for the command run on the other\n> end.\n> \n> and git-pull:\n> \n> --receive-pack=\n> Path to the git-receive-pack program on the remote end.\n> Sometimes useful when pushing to a remote repository over ssh,\n> and you do not have the program in a directory on the default\n> $PATH.\n\nThanks!\n\nI did completely miss this when I went through the manpage...\n\nI'm thinking I like the env var idea much more though. I can just export it\nin my shell and it works in both cases. I could of course alias the commands\nso I don't have to keep typing it everytime, but that's more painful still...\n\n--Kevin\n"},{"id":"45143","messageId":"1181922859.8626.7.camel@localhost","threadId":"8612","inReplyTo":"20070615154000.GK14677@menevado.ms.com","subject":"Re: [RFC][PATCH] Fix assumption that git is installed in a standard place on the remote end ssh","fromName":"Raimund Bauer","fromEmail":"ray007@gmx.net","sentAt":"2007-06-15T15:54:19Z","receivedAt":"2007-06-15T15:54:19Z","isPatch":true,"sender":{"key":"ray007@gmx.net","avatar":null},"body":"On Fri, 2007-06-15 at 11:40 -0400, Kevin Green wrote:\n> I'm thinking I like the env var idea much more though. I can just export it\n> in my shell and it works in both cases. I could of course alias the commands\n> so I don't have to keep typing it everytime, but that's more painful still...\n\ndo 'git config --help' and check the options\n\nremote..receivepack\nremote..uploadpack\n\n> --Kevin\n\n-- \nbest regards\n\n Ray\n"},{"id":"45300","messageId":"Pine.LNX.4.64.0706190114110.4059@racer.site","threadId":"8612","inReplyTo":"20070615154000.GK14677@menevado.ms.com","subject":"Re: [RFC][PATCH] Fix assumption that git is installed in a standard place on the remote end ssh","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2007-06-19T00:16:47Z","receivedAt":"2007-06-19T00:16:47Z","isPatch":true,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi,\n\nOn Fri, 15 Jun 2007, Kevin Green wrote:\n\n> I'm thinking I like the env var idea much more though. I can just \n> export it in my shell and it works in both cases.\n\nAnd it completely breaks down when you have more than one remotes. Or when \nyou cd to another project with another remote. Or etc. IOW it is fragile.\n\nClearly, the config approach is the only one which makes sense. This \ninformation is so closely coupled to a specific remote that you should \nstore it right where you store all the other remote information, too.\n\nCiao,\nDscho\n"},{"id":"45535","messageId":"20070622013026.GY14298@menevado.ms.com","threadId":"8612","inReplyTo":"Pine.LNX.4.64.0706190114110.4059@racer.site","subject":"Re: [RFC][PATCH] Fix assumption that git is installed in a standard place on the remote end ssh","fromName":"Kevin Green","fromEmail":"kevin.t.green@morganstanley.com","sentAt":"2007-06-22T01:30:26Z","receivedAt":"2007-06-22T01:30:26Z","isPatch":true,"sender":{"key":"kevin.t.green@morganstanley.com","avatar":null},"body":"On 06/18/07 20:16:47, Johannes Schindelin wrote:\n> Hi,\n> \n> On Fri, 15 Jun 2007, Kevin Green wrote:\n> \n> > I'm thinking I like the env var idea much more though. I can just \n> > export it in my shell and it works in both cases.\n> \n> And it completely breaks down when you have more than one remotes. Or when \n> you cd to another project with another remote. Or etc. IOW it is fragile.\n> \n> Clearly, the config approach is the only one which makes sense. This \n> information is so closely coupled to a specific remote that you should \n> store it right where you store all the other remote information, too.\n> \n\nYou're absolutely right. I agree, except that in _my_ environment git will\nbe in a non-standard path but *always* consistently in the same place. I'm being\ngreedy here. :)\n\nThe config approach is clearly the most versatile. The question I have is, is\nthere a good reason not to provide the third option of setting env var? I suppose that in the\nmore likely case this could cause more harm than good, i.e. maybe\nthis is too specific for my use case.\n\n\nThanks\n\n--Kevin\n"},{"id":"45560","messageId":"Pine.LNX.4.64.0706221140140.4059@racer.site","threadId":"8612","inReplyTo":"20070622013026.GY14298@menevado.ms.com","subject":"Re: [RFC][PATCH] Fix assumption that git is installed in a standard place on the remote end ssh","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2007-06-22T10:47:00Z","receivedAt":"2007-06-22T10:47:00Z","isPatch":true,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi,\n\nOn Thu, 21 Jun 2007, Kevin Green wrote:\n\n> On 06/18/07 20:16:47, Johannes Schindelin wrote:\n> > Hi,\n> > \n> > On Fri, 15 Jun 2007, Kevin Green wrote:\n> > \n> > > I'm thinking I like the env var idea much more though. I can just \n> > > export it in my shell and it works in both cases.\n> > \n> > And it completely breaks down when you have more than one remotes. Or when \n> > you cd to another project with another remote. Or etc. IOW it is fragile.\n> > \n> > Clearly, the config approach is the only one which makes sense. This \n> > information is so closely coupled to a specific remote that you should \n> > store it right where you store all the other remote information, too.\n> > \n> \n> You're absolutely right. I agree, except that in _my_ environment git \n> will be in a non-standard path but *always* consistently in the same \n> place. I'm being greedy here. :)\n\nNote that this \"solution\" will _only_ work for you.\n\n> The config approach is clearly the most versatile. The question I have \n> is, is there a good reason not to provide the third option of setting \n> env var? I suppose that in the more likely case this could cause more \n> harm than good, i.e. maybe this is too specific for my use case.\n\nSince it will _only_ work for you, I think there is more harm done than \ngood, by including that in mainline git. Just think of somebody seeing \nthis mentioned in the docs, not reading further properly, and just getting \nconfused, blaming it on Git.\n\nInstead, we have that wonderful config solution, which is the proper one \nanyway, and which does not confuse people, once they found it.\n\nHowever, Git is all about the freedom to fork and merge. So do the same as \nme: keep those changes in your local repo, and do not use mainline Git.\n\nFor example, I have this option \"-t\" to Git, which automatically tries to \ngive human-readable names to all the 40-character object names, and does \nnot change colouring. Thus, I can say\n\n\tgit -t log -p whatever.c\n\nto find exactly which commit introduced a certain feature (which I find by \nsearching the diffs). Then, I only have to copy&paste the nice commit name \ninto the mail/IRC where I am responding to, and be done.\n\nThis feature was not liked on the list, so it remains in my local fork \nforever (though it is also stored in the mail archives).\n\nCiao,\nDscho\n"}]}