{"thread":{"id":"2762","subject":"[RFC] Run hooks with a cleaner environment","startedAt":"2005-12-06T22:43:28Z","lastAt":"2005-12-07T18:57:30Z","messageCount":5,"participants":["Daniel Barkalow","Paul Serice","Junio C Hamano"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"13290","messageId":"Pine.LNX.4.64.0512061716030.25300@iabervon.org","threadId":"2762","inReplyTo":null,"subject":"[RFC] Run hooks with a cleaner environment","fromName":"Daniel Barkalow","fromEmail":"barkalow@iabervon.org","sentAt":"2005-12-06T22:43:28Z","receivedAt":"2005-12-06T22:43:28Z","isPatch":false,"sender":{"key":"barkalow@iabervon.org","avatar":"https://avatars.githubusercontent.com/u/55364219?v=4"},"body":"Currently, hooks/post-update is run in the environment that receive-pack \nis run. This means that there are a number of things that are \nunpredictable. I'd like to make it set things up in a more predictable and \nuseful way. The things I know are odd:\n\nstdout and stdin are connected to send-pack, either by broken pipes (for \nlocal pushes) or an ignored socket (via ssh). stdin should probably be \n/dev/null, and stdout should be either a log file or /dev/null. stderr is \nstill the push's stderr, which may or may not be desired.\n\nGIT_DIR is set to the repository that got the push, which may surprise \npeople who only use it in \"GIT_DIR=foo git ...\" form and don't expect it \never to be set from outside. Of course, it's potentially useful to know \nwhat repository is running the hook, but that doesn't have to be \ncommunicated in such a way that git programs will pick it up directly. \nOther environment variables could potentially be purged, too, but I don't \nthink that's as important, since the user probably knows about them.\n\ncwd is set to the push's cwd if it's local, maybe $HOME if it's over ssh. \nIt should probably always be $HOME, unless we want it to be $GIT_DIR.\n\nIs there anything else we want to regularize? Is there some sort of \nstandard behavior we should match, like CVS or cron?\n\n\t-Daniel\n*This .sig left intentionally blank*\n"},{"id":"13298","messageId":"43962AAE.4040704@serice.net","threadId":"2762","inReplyTo":"Pine.LNX.4.64.0512061716030.25300@iabervon.org","subject":"Re: [RFC] Run hooks with a cleaner environment","fromName":"Paul Serice","fromEmail":"paul@serice.net","sentAt":"2005-12-07T00:19:58Z","receivedAt":"2005-12-07T00:19:58Z","isPatch":false,"sender":{"key":"paul@serice.net","avatar":null},"body":"> Currently, hooks/post-update is run in the environment that\n> receive-pack is run. This means that there are a number of things\n> that are unpredictable. I'd like to make it set things up in a more\n> predictable and useful way.\n\nI'd like to second this. I've been bitten by two of the three issues\nyou've raised.\n\n\n> stdout and stdin are connected to send-pack, either by broken pipes\n> (for local pushes) or an ignored socket (via ssh). stdin should\n> probably be /dev/null, and stdout should be either a log file or\n> /dev/null. stderr is still the push's stderr, which may or may not\n> be desired.\n\nIf there is a controlling terminal and nothing else git-related is\nreading from it, I'd like for stdout and stderr to be reconnected.\n\n\nPaul Serice\n"},{"id":"13300","messageId":"7voe3tzqn8.fsf@assigned-by-dhcp.cox.net","threadId":"2762","inReplyTo":"Pine.LNX.4.64.0512061716030.25300@iabervon.org","subject":"Re: [RFC] Run hooks with a cleaner environment","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2005-12-07T00:39:55Z","receivedAt":"2005-12-07T00:39:55Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Daniel Barkalow writes:\n\n> GIT_DIR is set to the repository that got the push,\n\nThat is done by receive-pack; it chdir()s into the repository\nand does its thing, and the hooks are called from there; I'd\nexpect cwd to be the repository ('.git'), GIT_DIR to be dot\n('.').\n\nI think doing the \"unset GIT_DIR\" to be the first thing if you\nwant to access some other repository is documented somewhere but\nif not please send a patch to document it.\n\nAs to file descriptors, I think duping the output to original\nstderr might make sense, but I do not know what breaks, so\ninterested parties may want to test it out and submit a tested\npatch for inclusion.\n"},{"id":"13323","messageId":"Pine.LNX.4.64.0512071236260.25300@iabervon.org","threadId":"2762","inReplyTo":"7voe3tzqn8.fsf@assigned-by-dhcp.cox.net","subject":"Re: [RFC] Run hooks with a cleaner environment","fromName":"Daniel Barkalow","fromEmail":"barkalow@iabervon.org","sentAt":"2005-12-07T17:47:39Z","receivedAt":"2005-12-07T17:47:39Z","isPatch":false,"sender":{"key":"barkalow@iabervon.org","avatar":"https://avatars.githubusercontent.com/u/55364219?v=4"},"body":"On Tue, 6 Dec 2005, Junio C Hamano wrote:\n\n> Daniel Barkalow writes:\n> \n> > GIT_DIR is set to the repository that got the push,\n> \n> That is done by receive-pack; it chdir()s into the repository\n> and does its thing, and the hooks are called from there; I'd\n> expect cwd to be the repository ('.git'), GIT_DIR to be dot\n> ('.').\n\nI thought I was seeing the full path of the repository as GIT_DIR and I \ndidn't check the cwd.\n\n> I think doing the \"unset GIT_DIR\" to be the first thing if you\n> want to access some other repository is documented somewhere but\n> if not please send a patch to document it.\n\nI didn't see it in the place \"grep post-update Documentation/*\" returned, \nso we need something. (Actually, the main thing is to specify that nothing \nelse special is set, because the GIT_DIR thing was pretty obvious, but I \nthen didn't know if my problems were due to something else undocumented.)\n\n> As to file descriptors, I think duping the output to original\n> stderr might make sense, but I do not know what breaks, so\n> interested parties may want to test it out and submit a tested\n> patch for inclusion.\n\nI'll send a patch tonight which works for me, but it should probably be \nchecked over by people who are good at this sort of stuff. I've got a \n\"/dev/null\" patch; I'll look into a version that tries to find a \ncontrolling tty (which could be really interesting, since you could then \nhave the hook get input from the user), or at least copy stderr if \npossible.\n\nFor reference, the error I was getting was a broken pipe writing to stdout \n(as git merge does somewhere) when I've pushed locally.\n\n\t-Daniel\n*This .sig left intentionally blank*\n"},{"id":"13327","messageId":"7voe3srazp.fsf@assigned-by-dhcp.cox.net","threadId":"2762","inReplyTo":"Pine.LNX.4.64.0512071236260.25300@iabervon.org","subject":"Re: [RFC] Run hooks with a cleaner environment","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2005-12-07T18:57:30Z","receivedAt":"2005-12-07T18:57:30Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Daniel Barkalow writes:\n\n> On Tue, 6 Dec 2005, Junio C Hamano wrote:\n>\n>> Daniel Barkalow writes:\n>> \n>> > GIT_DIR is set to the repository that got the push,\n>> \n>> That is done by receive-pack; it chdir()s into the repository\n>> and does its thing, and the hooks are called from there; I'd\n>> expect cwd to be the repository ('.git'), GIT_DIR to be dot\n>> ('.').\n>\n> I thought I was seeing the full path of the repository as GIT_DIR and I \n> didn't check the cwd.\n\nI do not do this myself, but I was wondering what would happen\nif somebody has \"export GIT_DIR=/var/filfre\" in ~/.profile.\n\nWell, I know what would happen, actually --- things would not\nwork when you do fetch/push because the tools want to use the\npath given from the other end but the environment overrides it\nwith GIT_DIR.\n"}]}