{"thread":{"id":"31632","subject":"GIT_DIR vs. --git-dir","startedAt":"2012-09-24T07:19:27Z","lastAt":"2012-09-25T07:27:47Z","messageCount":17,"participants":["Michael J Gruber","Nguyen Thai Ngoc Duy","Andreas Schwab","Junio C Hamano","Jeff King","Jan Engelhardt"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"199788","messageId":"5060097F.9050203@drmicha.warpmail.net","threadId":"31632","inReplyTo":null,"subject":"GIT_DIR vs. --git-dir","fromName":"Michael J Gruber","fromEmail":"git@drmicha.warpmail.net","sentAt":"2012-09-24T07:19:27Z","receivedAt":"2012-09-24T07:19:27Z","isPatch":false,"sender":{"key":"git@grubix.eu","avatar":"https://avatars.githubusercontent.com/u/233215?v=4"},"body":"[mjg@localhost ~]$ GIT_DIR=~/.githome git rev-parse --show-toplevel\n/home/mjg\n\n[mjg@localhost ~]$ git --git-dir=~/.githome rev-parse --show-toplevel\nfatal: Not a git repository: '~/.githome'\n\nHuh? Ok, so most users probably would not try further and blame git, but:\n\n[mjg@localhost ~]$ git --git-dir=/home/mjg/.githome rev-parse\n--show-toplevel\n/home/mjg\n\n(All this is with core.worktree set to /home/mjg.)\n\nSo, while I do understand that we don't expand '~' in any of these cases\nand it's only a matter of bash tilde expansion kicking in or not, we\nmight want to do something about it. (--git-dir=$HOME/.githome gets\nexpanded, as well, and --git-dir=.githome works from the appropriate cwd\nonly).\n\nMichael\n"},{"id":"199790","messageId":"CACsJy8DHGtktnvvziA_+Fp6a4VFsE9_=zkWKNBJU7Ro_QO+==A@mail.gmail.com","threadId":"31632","inReplyTo":"5060097F.9050203@drmicha.warpmail.net","subject":"Re: GIT_DIR vs. --git-dir","fromName":"Nguyen Thai Ngoc Duy","fromEmail":"pclouds@gmail.com","sentAt":"2012-09-24T07:41:28Z","receivedAt":"2012-09-24T07:41:28Z","isPatch":false,"sender":{"key":"pclouds@gmail.com","avatar":"https://avatars.githubusercontent.com/u/720?v=4"},"body":"On Mon, Sep 24, 2012 at 2:19 PM, Michael J Gruber\n wrote:\n> [mjg@localhost ~]$ GIT_DIR=~/.githome git rev-parse --show-toplevel\n> /home/mjg\n>\n> [mjg@localhost ~]$ git --git-dir=~/.githome rev-parse --show-toplevel\n> fatal: Not a git repository: '~/.githome'\n>\n> Huh?\n\nThe message looks pretty clear to me that ~ is not expanded.\n\n> Ok, so most users probably would not try further and blame git, but:\n>\n> [mjg@localhost ~]$ git --git-dir=/home/mjg/.githome rev-parse\n> --show-toplevel\n> /home/mjg\n>\n> (All this is with core.worktree set to /home/mjg.)\n>\n> So, while I do understand that we don't expand '~' in any of these cases\n> and it's only a matter of bash tilde expansion kicking in or not, we\n> might want to do something about it. (--git-dir=$HOME/.githome gets\n> expanded, as well, and --git-dir=.githome works from the appropriate cwd\n> only).\n\n\"~\" is a shell feature. Know your shell. If we make an exception for\n--git-dir, we might have to support --blahblah=~/somewhere. That's a\nlot of changes and we might mistakenly over-expand something. Users\nrunning git on cmd.exe may get surprised that \"~\" is expanded. We\ncould print an advice \"did you mean $HOME/.githome?\". That could still\nbe a lot of changes, but it's no-op so less worries of breaking\nsomething. I prefer doing nothing in this case.\n-- \nDuy\n"},{"id":"199791","messageId":"50601274.80506@drmicha.warpmail.net","threadId":"31632","inReplyTo":"CACsJy8DHGtktnvvziA_+Fp6a4VFsE9_=zkWKNBJU7Ro_QO+==A@mail.gmail.com","subject":"Re: GIT_DIR vs. --git-dir","fromName":"Michael J Gruber","fromEmail":"git@drmicha.warpmail.net","sentAt":"2012-09-24T07:57:40Z","receivedAt":"2012-09-24T07:57:40Z","isPatch":false,"sender":{"key":"git@grubix.eu","avatar":"https://avatars.githubusercontent.com/u/233215?v=4"},"body":"Nguyen Thai Ngoc Duy venit, vidit, dixit 24.09.2012 09:41:\n> On Mon, Sep 24, 2012 at 2:19 PM, Michael J Gruber\n> wrote:\n>> [mjg@localhost ~]$ GIT_DIR=~/.githome git rev-parse --show-toplevel\n>> /home/mjg\n>>\n>> [mjg@localhost ~]$ git --git-dir=~/.githome rev-parse --show-toplevel\n>> fatal: Not a git repository: '~/.githome'\n>>\n>> Huh?\n> \n> The message looks pretty clear to me that ~ is not expanded.\n\n...to you and me, of course, but the point is whether we can be more\nhelpful to most users.\n\n> \n>> Ok, so most users probably would not try further and blame git, but:\n>>\n>> [mjg@localhost ~]$ git --git-dir=/home/mjg/.githome rev-parse\n>> --show-toplevel\n>> /home/mjg\n>>\n>> (All this is with core.worktree set to /home/mjg.)\n>>\n>> So, while I do understand that we don't expand '~' in any of these cases\n>> and it's only a matter of bash tilde expansion kicking in or not, we\n>> might want to do something about it. (--git-dir=$HOME/.githome gets\n>> expanded, as well, and --git-dir=.githome works from the appropriate cwd\n>> only).\n> \n> \"~\" is a shell feature. Know your shell. If we make an exception for\n> --git-dir, we might have to support --blahblah=~/somewhere. That's a\n> lot of changes and we might mistakenly over-expand something. Users\n> running git on cmd.exe may get surprised that \"~\" is expanded. We\n> could print an advice \"did you mean $HOME/.githome?\". That could still\n> be a lot of changes, but it's no-op so less worries of breaking\n> something. I prefer doing nothing in this case.\n\nFirst of all, we expand '~' in other cases (basically all config vars)\nta) where it's unambiguously a path. And --git-dir really is the\nsensible version of core.gitdir (which would make no sense, of course).\n\nThen, \"we\" refuse to make \"~2\" a shorthand for \"HEAD~2\" in the revision\nparser because \"~2\" has a meaning for certain shells in certain\nsituations (depending on your dirstack) and would need to be quoted, so\nwe certainly take into account how the shell behaves.\n\nIt might be difficult to implement, but I'm sorry I can't follow the\nargumentation above at all; it's not based on what we do in other places\nand other cases.\n\nMichael\n"},{"id":"199792","messageId":"CACsJy8ChOd-684V8Dsbwf2nOsW8UMnYn_vo5MAZ6ixyq_QvMkw@mail.gmail.com","threadId":"31632","inReplyTo":"50601274.80506@drmicha.warpmail.net","subject":"Re: GIT_DIR vs. --git-dir","fromName":"Nguyen Thai Ngoc Duy","fromEmail":"pclouds@gmail.com","sentAt":"2012-09-24T09:53:29Z","receivedAt":"2012-09-24T09:53:29Z","isPatch":false,"sender":{"key":"pclouds@gmail.com","avatar":"https://avatars.githubusercontent.com/u/720?v=4"},"body":"On Mon, Sep 24, 2012 at 2:57 PM, Michael J Gruber\n wrote:\n> It might be difficult to implement, but I'm sorry I can't follow the\n> argumentation above at all; it's not based on what we do in other places\n> and other cases.\n\nMy point is, what's so special about --git-dir? what about\n--work-tree, or \"commit -F path\"? It's hard to draw a line there.\nConfig files are a special case, because git is the only one that\nreads the file. \"~\" expansion depends on shell setting. If users turn\nit off, they may be surprised that \"~foo\" is turned to /home/foo while\nthey really mean \"~foo\". Warning is the only sensible thing we could\ndo.\n-- \nDuy\n"},{"id":"199797","messageId":"5060588D.3080202@drmicha.warpmail.net","threadId":"31632","inReplyTo":"CACsJy8ChOd-684V8Dsbwf2nOsW8UMnYn_vo5MAZ6ixyq_QvMkw@mail.gmail.com","subject":"Re: GIT_DIR vs. --git-dir","fromName":"Michael J Gruber","fromEmail":"git@drmicha.warpmail.net","sentAt":"2012-09-24T12:56:45Z","receivedAt":"2012-09-24T12:56:45Z","isPatch":false,"sender":{"key":"git@grubix.eu","avatar":"https://avatars.githubusercontent.com/u/233215?v=4"},"body":"Nguyen Thai Ngoc Duy venit, vidit, dixit 24.09.2012 11:53:\n> On Mon, Sep 24, 2012 at 2:57 PM, Michael J Gruber\n> wrote:\n>> It might be difficult to implement, but I'm sorry I can't follow the\n>> argumentation above at all; it's not based on what we do in other places\n>> and other cases.\n> \n> My point is, what's so special about --git-dir? what about\n> --work-tree, or \"commit -F path\"? It's hard to draw a line there.\n\nSure those should follow, especially work-tree.\n\n> Config files are a special case, because git is the only one that\n> reads the file. \"~\" expansion depends on shell setting. If users turn\n> it off, they may be surprised that \"~foo\" is turned to /home/foo while\n> they really mean \"~foo\". Warning is the only sensible thing we could\n> do.\n\nBut that argument applies to config files in exactly the same way as it\napplies to command line arguments. Git is the only one reading them. So\nwhy not leave it up to Git to decide about expansion?\n\nOn the other hand: If Git expanding arguments is surprising, why is it\nunsurprising if Git expands config values?\n\nYou know the implementation, so there are no surprises for you. But once\nin a while we can pretend to design Git for those who just use it.\n\nMichael\n"},{"id":"199798","messageId":"fdeaa78c0a520ce80e6d2cb09978dab348104eaf.1348491039.git.git@drmicha.warpmail.net","threadId":"31632","inReplyTo":"5060588D.3080202@drmicha.warpmail.net","subject":"[RFC/PATCH] git: expand user path in --git-dir","fromName":"Michael J Gruber","fromEmail":"git@drmicha.warpmail.net","sentAt":"2012-09-24T12:57:20Z","receivedAt":"2012-09-24T12:57:20Z","isPatch":true,"sender":{"key":"git@grubix.eu","avatar":"https://avatars.githubusercontent.com/u/233215?v=4"},"body":"Currently, all paths in the config file are subject to tilde expansion\nfor user paths while the argument to --git-dir is not expanded, and\nneither are paths in the environment such as GIT_DIR. From the user\nperspective, though, the two commands\n\nGIT_DIR=~user/foo git command\ngit --git-dir=~user/foo command\n\ncurrently behave differently because in the first case the shell would\nperform tilde expansion, but not in the second. Also, one may argue that\nspecifying '--git-dir=' is like specifying a config variable (which\ncannot exist for this purpose).\n\nThus, make arguments to '--git-dir' undergo tilde expansion.\n---\nSo, here's a simple patch implementing tilde expansion for --git-dir. It passes\nall tests. It's done doing the expansion on the setting side.\n\nAlternatively, one might do it on the getting side, i.e. when reading GIT_DIR,\nso that paths passed directly through the environment undergo tilde expansion\nas well. We don't do this for any environment variable yet, so I didn't go\nthat far.\n\nSigned-off-by: Michael J Gruber \n---\n git.c | 20 ++++++++++++++++++--\n 1 file changed, 18 insertions(+), 2 deletions(-)\n\ndiff --git a/git.c b/git.c\nindex 8788b32..35e8011 100644\n--- a/git.c\n+++ b/git.c\n@@ -64,6 +64,22 @@ static void commit_pager_choice(void) {\n \t}\n }\n \n+static int expand_path_setenv(const char *name, const char *value, int overwrite)\n+{\n+\tint ret;\n+\tconst char *expanded;\n+\n+\tif (!value)\n+\t\treturn setenv(name, value, overwrite);\n+\n+\texpanded = expand_user_path(value);\n+\tif (!expanded)\n+\t\tdie(\"Failed to expand user dir in: '%s'\", value);\n+\tret = setenv(name, expanded, overwrite);\n+\tfree((void *)expanded);\n+\treturn ret;\n+}\n+\n static int handle_options(const char ***argv, int *argc, int *envchanged)\n {\n \tconst char **orig_argv = *argv;\n@@ -117,13 +133,13 @@ static int handle_options(const char ***argv, int *argc, int *envchanged)\n \t\t\t\tfprintf(stderr, \"No directory given for --git-dir.\\n\" );\n \t\t\t\tusage(git_usage_string);\n \t\t\t}\n-\t\t\tsetenv(GIT_DIR_ENVIRONMENT, (*argv)[1], 1);\n+\t\t\texpand_path_setenv(GIT_DIR_ENVIRONMENT, (*argv)[1], 1);\n \t\t\tif (envchanged)\n \t\t\t\t*envchanged = 1;\n \t\t\t(*argv)++;\n \t\t\t(*argc)--;\n \t\t} else if (!prefixcmp(cmd, \"--git-dir=\")) {\n-\t\t\tsetenv(GIT_DIR_ENVIRONMENT, cmd + 10, 1);\n+\t\t\texpand_path_setenv(GIT_DIR_ENVIRONMENT, cmd + 10, 1);\n \t\t\tif (envchanged)\n \t\t\t\t*envchanged = 1;\n \t\t} else if (!strcmp(cmd, \"--namespace\")) {\n-- \n1.7.12.1.580.gb9ed689\n"},{"id":"199802","messageId":"m2zk4fa6ep.fsf@igel.home","threadId":"31632","inReplyTo":"5060588D.3080202@drmicha.warpmail.net","subject":"Re: GIT_DIR vs. --git-dir","fromName":"Andreas Schwab","fromEmail":"schwab@linux-m68k.org","sentAt":"2012-09-24T13:37:18Z","receivedAt":"2012-09-24T13:37:18Z","isPatch":false,"sender":{"key":"schwab@linux-m68k.org","avatar":"https://avatars.githubusercontent.com/u/2175493?v=4"},"body":"Michael J Gruber writes:\n\n> But that argument applies to config files in exactly the same way as it\n> applies to command line arguments. Git is the only one reading them. So\n> why not leave it up to Git to decide about expansion?\n\nCommand line arguments are first processed by the shell, handling\nexpansions like $HOME. It is part of the Unix philosophy that expansion\nof command lines is left to the shell.\n\n> On the other hand: If Git expanding arguments is surprising, why is it\n> unsurprising if Git expands config values?\n\nThe config file is not processed by the shell.\n\nAndreas.\n\n-- \nAndreas Schwab, schwab@linux-m68k.org\nGPG Key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5\n\"And now for something completely different.\"\n"},{"id":"199809","messageId":"7vipb31o9x.fsf@alter.siamese.dyndns.org","threadId":"31632","inReplyTo":"CACsJy8DHGtktnvvziA_+Fp6a4VFsE9_=zkWKNBJU7Ro_QO+==A@mail.gmail.com","subject":"Re: GIT_DIR vs. --git-dir","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2012-09-24T14:36:10Z","receivedAt":"2012-09-24T14:36:10Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Nguyen Thai Ngoc Duy writes:\n\n> \"~\" is a shell feature. Know your shell. If we make an exception for\n> --git-dir, we might have to support --blahblah=~/somewhere.\n\nCorrect but not entirely true.\n\nWhen we know --git-dir= must name a path, we should be able to\ndo better. See OPT_FILENAME in >parse-optios.h>, for inspiration.\n\nMJG's patch later in this thread is conceptually OK but I do not\nthink it should introduce a \"expand and then setenv\" helper that\nwon't be useful unless the variable is GIT_DIR. That pattern does\nnot appear that often, and smells like a bad API design taste.\n"},{"id":"199810","messageId":"20120924144929.GA10349@sigill.intra.peff.net","threadId":"31632","inReplyTo":"5060097F.9050203@drmicha.warpmail.net","subject":"Re: GIT_DIR vs. --git-dir","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2012-09-24T14:49:29Z","receivedAt":"2012-09-24T14:49:29Z","isPatch":false,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Mon, Sep 24, 2012 at 09:19:27AM +0200, Michael J Gruber wrote:\n\n> [mjg@localhost ~]$ GIT_DIR=~/.githome git rev-parse --show-toplevel\n> /home/mjg\n> \n> [mjg@localhost ~]$ git --git-dir=~/.githome rev-parse --show-toplevel\n> fatal: Not a git repository: '~/.githome'\n> \n> Huh? Ok, so most users probably would not try further and blame git, but:\n> \n> [mjg@localhost ~]$ git --git-dir=/home/mjg/.githome rev-parse\n> --show-toplevel\n> /home/mjg\n> \n> (All this is with core.worktree set to /home/mjg.)\n> \n> So, while I do understand that we don't expand '~' in any of these cases\n> and it's only a matter of bash tilde expansion kicking in or not, we\n> might want to do something about it. (--git-dir=$HOME/.githome gets\n> expanded, as well, and --git-dir=.githome works from the appropriate cwd\n> only).\n\nBash is even weirder than you might think. Try this:\n\n $ echo ~/foo\n /home/peff/foo\n\n $ echo arg=~/foo\n arg=/home/peff/foo\n\n $ echo --arg=~/foo\n --arg=~/foo\n\nThat is, it expands on the right-hand side of an \"=\" (which, from my\nreading of the bash manual, means it considers it a word split), but\nrefuses to expand after an \"=\" that is part of a long option.\n\nThe first one is definitely correct. It would be convenient for your use\ncase to expand the third one, and it logically follows from the second\none. However, dash does not expand the second one. I'm not sure if this\nis a bug in bash, or simply a grey area where the two shells do not\nagree.\n\nBut it makes me wonder if the world would be better served by a bash\noption to always enable tilde expansion after an \"=\". That would solve\nyour issue, and it would make the same feature work for every other git\nlong option, as well as for other programs.\n\n-Peff\n"},{"id":"199811","messageId":"5060736D.5020609@drmicha.warpmail.net","threadId":"31632","inReplyTo":"7vipb31o9x.fsf@alter.siamese.dyndns.org","subject":"Re: GIT_DIR vs. --git-dir","fromName":"Michael J Gruber","fromEmail":"git@drmicha.warpmail.net","sentAt":"2012-09-24T14:51:25Z","receivedAt":"2012-09-24T14:51:25Z","isPatch":false,"sender":{"key":"git@grubix.eu","avatar":"https://avatars.githubusercontent.com/u/233215?v=4"},"body":"Junio C Hamano venit, vidit, dixit 24.09.2012 16:36:\n> Nguyen Thai Ngoc Duy writes:\n> \n>> \"~\" is a shell feature. Know your shell. If we make an exception for\n>> --git-dir, we might have to support --blahblah=~/somewhere.\n> \n> Correct but not entirely true.\n> \n> When we know --git-dir= must name a path, we should be able to\n> do better. See OPT_FILENAME in >parse-optios.h>, for inspiration.\n> \n> MJG's patch later in this thread is conceptually OK but I do not\n> think it should introduce a \"expand and then setenv\" helper that\n> won't be useful unless the variable is GIT_DIR. That pattern does\n> not appear that often, and smells like a bad API design taste.\n\nI can't quite parse. My little helper can be used for any path\nenvironment variable, not just GIT_DIR. Granted, there aren't that many\nin use.\n\nDo you suggest tilde expansion right in fix_filename() (i.e. for all\nOPT_FILE options), or some OPT_FILENAME_EXPANDED which may or may not be\nused by some config? There's git_config_pathname() already which does\nexpansion, of course.\n\nMichael\n"},{"id":"199812","messageId":"20120924145208.GB10349@sigill.intra.peff.net","threadId":"31632","inReplyTo":"fdeaa78c0a520ce80e6d2cb09978dab348104eaf.1348491039.git.git@drmicha.warpmail.net","subject":"Re: [RFC/PATCH] git: expand user path in --git-dir","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2012-09-24T14:52:08Z","receivedAt":"2012-09-24T14:52:08Z","isPatch":true,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Mon, Sep 24, 2012 at 02:57:20PM +0200, Michael J Gruber wrote:\n\n> Currently, all paths in the config file are subject to tilde expansion\n> for user paths while the argument to --git-dir is not expanded, and\n> neither are paths in the environment such as GIT_DIR. From the user\n> perspective, though, the two commands\n> \n> GIT_DIR=~user/foo git command\n> git --git-dir=~user/foo command\n> \n> currently behave differently because in the first case the shell would\n> perform tilde expansion, but not in the second. Also, one may argue that\n> specifying '--git-dir=' is like specifying a config variable (which\n> cannot exist for this purpose).\n> \n> Thus, make arguments to '--git-dir' undergo tilde expansion.\n> ---\n> So, here's a simple patch implementing tilde expansion for --git-dir. It passes\n> all tests. It's done doing the expansion on the setting side.\n> \n> Alternatively, one might do it on the getting side, i.e. when reading GIT_DIR,\n> so that paths passed directly through the environment undergo tilde expansion\n> as well. We don't do this for any environment variable yet, so I didn't go\n> that far.\n\nKeep in mind that every layer of expansion you add is a layer of quoting\nsomebody else must do in order to pass through certain paths. I will\nadmit that putting a \"~\" into a path is relatively uncommon, but this\npatch is a regression for anybody who does so with --git-dir (they will\nnow need to quote the \"~\" against not just their shell, but against\ngit). Expanding environment variables like GIT_DIR means that we would\nalso need to quote things we put into GIT_DIR.\n\n-Peff\n"},{"id":"199813","messageId":"50607442.3040906@drmicha.warpmail.net","threadId":"31632","inReplyTo":"20120924144929.GA10349@sigill.intra.peff.net","subject":"Re: GIT_DIR vs. --git-dir","fromName":"Michael J Gruber","fromEmail":"git@drmicha.warpmail.net","sentAt":"2012-09-24T14:54:58Z","receivedAt":"2012-09-24T14:54:58Z","isPatch":false,"sender":{"key":"git@grubix.eu","avatar":"https://avatars.githubusercontent.com/u/233215?v=4"},"body":"Jeff King venit, vidit, dixit 24.09.2012 16:49:\n> On Mon, Sep 24, 2012 at 09:19:27AM +0200, Michael J Gruber wrote:\n> \n>> [mjg@localhost ~]$ GIT_DIR=~/.githome git rev-parse --show-toplevel\n>> /home/mjg\n>>\n>> [mjg@localhost ~]$ git --git-dir=~/.githome rev-parse --show-toplevel\n>> fatal: Not a git repository: '~/.githome'\n>>\n>> Huh? Ok, so most users probably would not try further and blame git, but:\n>>\n>> [mjg@localhost ~]$ git --git-dir=/home/mjg/.githome rev-parse\n>> --show-toplevel\n>> /home/mjg\n>>\n>> (All this is with core.worktree set to /home/mjg.)\n>>\n>> So, while I do understand that we don't expand '~' in any of these cases\n>> and it's only a matter of bash tilde expansion kicking in or not, we\n>> might want to do something about it. (--git-dir=$HOME/.githome gets\n>> expanded, as well, and --git-dir=.githome works from the appropriate cwd\n>> only).\n> \n> Bash is even weirder than you might think. Try this:\n> \n> $ echo ~/foo\n> /home/peff/foo\n> \n> $ echo arg=~/foo\n> arg=/home/peff/foo\n> \n> $ echo --arg=~/foo\n> --arg=~/foo\n> \n> That is, it expands on the right-hand side of an \"=\" (which, from my\n> reading of the bash manual, means it considers it a word split), but\n> refuses to expand after an \"=\" that is part of a long option.\n> \n> The first one is definitely correct. It would be convenient for your use\n> case to expand the third one, and it logically follows from the second\n> one. However, dash does not expand the second one. I'm not sure if this\n> is a bug in bash, or simply a grey area where the two shells do not\n> agree.\n> \n> But it makes me wonder if the world would be better served by a bash\n> option to always enable tilde expansion after an \"=\". That would solve\n> your issue, and it would make the same feature work for every other git\n> long option, as well as for other programs.\n\nYes, in some sense this is working around a bash \"feature\". I don't\nreally care too much personally.\n\nNote that we also have \"git -c \"config.var=value\" which, again \"works\"\nbecause we expand config vars.\n\nSo, technically there are no surprises if you know the shell's expansion\nrules. But still...\n\nMichael\n"},{"id":"199815","messageId":"506074F7.2000500@drmicha.warpmail.net","threadId":"31632","inReplyTo":"20120924145208.GB10349@sigill.intra.peff.net","subject":"Re: [RFC/PATCH] git: expand user path in --git-dir","fromName":"Michael J Gruber","fromEmail":"git@drmicha.warpmail.net","sentAt":"2012-09-24T14:57:59Z","receivedAt":"2012-09-24T14:57:59Z","isPatch":true,"sender":{"key":"git@grubix.eu","avatar":"https://avatars.githubusercontent.com/u/233215?v=4"},"body":"Jeff King venit, vidit, dixit 24.09.2012 16:52:\n> On Mon, Sep 24, 2012 at 02:57:20PM +0200, Michael J Gruber wrote:\n> \n>> Currently, all paths in the config file are subject to tilde expansion\n>> for user paths while the argument to --git-dir is not expanded, and\n>> neither are paths in the environment such as GIT_DIR. From the user\n>> perspective, though, the two commands\n>>\n>> GIT_DIR=~user/foo git command\n>> git --git-dir=~user/foo command\n>>\n>> currently behave differently because in the first case the shell would\n>> perform tilde expansion, but not in the second. Also, one may argue that\n>> specifying '--git-dir=' is like specifying a config variable (which\n>> cannot exist for this purpose).\n>>\n>> Thus, make arguments to '--git-dir' undergo tilde expansion.\n>> ---\n>> So, here's a simple patch implementing tilde expansion for --git-dir. It passes\n>> all tests. It's done doing the expansion on the setting side.\n>>\n>> Alternatively, one might do it on the getting side, i.e. when reading GIT_DIR,\n>> so that paths passed directly through the environment undergo tilde expansion\n>> as well. We don't do this for any environment variable yet, so I didn't go\n>> that far.\n> \n> Keep in mind that every layer of expansion you add is a layer of quoting\n> somebody else must do in order to pass through certain paths. I will\n> admit that putting a \"~\" into a path is relatively uncommon, but this\n> patch is a regression for anybody who does so with --git-dir (they will\n> now need to quote the \"~\" against not just their shell, but against\n> git). Expanding environment variables like GIT_DIR means that we would\n> also need to quote things we put into GIT_DIR.\n\n...as far as \"~\" is concerned, yes. We don't do a full expansion like\nthe shell does (or doesn't).\n\nProbably \"--git-dir\" is hidden well enough to be for the initiated only.\nAs for the other path options, we can always blame bash. It's got its\nname for a reason ;)\n\nMichael\n"},{"id":"199819","messageId":"m2d31ba0lw.fsf@igel.home","threadId":"31632","inReplyTo":"20120924144929.GA10349@sigill.intra.peff.net","subject":"Re: GIT_DIR vs. --git-dir","fromName":"Andreas Schwab","fromEmail":"schwab@linux-m68k.org","sentAt":"2012-09-24T15:42:35Z","receivedAt":"2012-09-24T15:42:35Z","isPatch":false,"sender":{"key":"schwab@linux-m68k.org","avatar":"https://avatars.githubusercontent.com/u/2175493?v=4"},"body":"Jeff King writes:\n\n> Bash is even weirder than you might think. Try this:\n>\n> $ echo ~/foo\n> /home/peff/foo\n>\n> $ echo arg=~/foo\n> arg=/home/peff/foo\n>\n> $ echo --arg=~/foo\n> --arg=~/foo\n\nBash expands all arguments that look like variable assignments. That\nlets you write \"export arg=~/foo\" even though a POSIX shell wouldn't\ntilde expand it.\n\nAndreas.\n\n-- \nAndreas Schwab, schwab@linux-m68k.org\nGPG Key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5\n\"And now for something completely different.\"\n"},{"id":"199830","messageId":"7vvcf3z5tu.fsf@alter.siamese.dyndns.org","threadId":"31632","inReplyTo":"fdeaa78c0a520ce80e6d2cb09978dab348104eaf.1348491039.git.git@drmicha.warpmail.net","subject":"Re: [RFC/PATCH] git: expand user path in --git-dir","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2012-09-24T17:30:37Z","receivedAt":"2012-09-24T17:30:37Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Michael J Gruber writes:\n\n> Currently, all paths in the config file are subject to tilde expansion\n> for user paths while the argument to --git-dir is not expanded, and\n> neither are paths in the environment such as GIT_DIR. From the user\n> perspective, though, the two commands\n>\n> GIT_DIR=~user/foo git command\n> git --git-dir=~user/foo command\n>\n> currently behave differently because in the first case the shell would\n> perform tilde expansion, but not in the second. Also, one may argue that\n> specifying '--git-dir=' is like specifying a config variable (which\n> cannot exist for this purpose).\n>\n> Thus, make arguments to '--git-dir' undergo tilde expansion.\n> ---\n> So, here's a simple patch implementing tilde expansion for --git-dir. It passes\n> all tests. It's done doing the expansion on the setting side.\n\nThis looks sensible, as long as there is no potential caller within\nthis file that wants user-path expansion and that does _not_ want to\nexport the result to an environment.\n\nThe helper will be usable as-is for --work-dir, which does want to\nexport the result to an environment. We would want --exec-path=\nhandle its parameter the same way, but that one has its own setenv()\nelsewhere, so \"expand-path-setenv()\" helper would not help it very\nmuch. The caller of git_set_argv_exec_path() needs to do the\nexpanding (and freeing after it makes the call) itself.\n\n> Alternatively, one might do it on the getting side, i.e. when reading GIT_DIR,\n> so that paths passed directly through the environment undergo tilde expansion\n> as well. We don't do this for any environment variable yet, so I didn't go\n> that far.\n>\n> Signed-off-by: Michael J Gruber \n> ---\n> git.c | 20 ++++++++++++++++++--\n> 1 file changed, 18 insertions(+), 2 deletions(-)\n>\n> diff --git a/git.c b/git.c\n> index 8788b32..35e8011 100644\n> --- a/git.c\n> +++ b/git.c\n> @@ -64,6 +64,22 @@ static void commit_pager_choice(void) {\n> \t}\n> }\n> \n> +static int expand_path_setenv(const char *name, const char *value, int overwrite)\n> +{\n> +\tint ret;\n> +\tconst char *expanded;\n> +\n> +\tif (!value)\n> +\t\treturn setenv(name, value, overwrite);\n> +\n> +\texpanded = expand_user_path(value);\n> +\tif (!expanded)\n> +\t\tdie(\"Failed to expand user dir in: '%s'\", value);\n\nThis should say where the 'value' came from (e.g. \"--git-dir=\" on\nthe command line).\n\n> +\tret = setenv(name, expanded, overwrite);\n> +\tfree((void *)expanded);\n> +\treturn ret;\n> +}\n> +\n> static int handle_options(const char ***argv, int *argc, int *envchanged)\n> {\n> \tconst char **orig_argv = *argv;\n> @@ -117,13 +133,13 @@ static int handle_options(const char ***argv, int *argc, int *envchanged)\n> \t\t\t\tfprintf(stderr, \"No directory given for --git-dir.\\n\" );\n> \t\t\t\tusage(git_usage_string);\n> \t\t\t}\n> -\t\t\tsetenv(GIT_DIR_ENVIRONMENT, (*argv)[1], 1);\n> +\t\t\texpand_path_setenv(GIT_DIR_ENVIRONMENT, (*argv)[1], 1);\n> \t\t\tif (envchanged)\n> \t\t\t\t*envchanged = 1;\n> \t\t\t(*argv)++;\n> \t\t\t(*argc)--;\n> \t\t} else if (!prefixcmp(cmd, \"--git-dir=\")) {\n> -\t\t\tsetenv(GIT_DIR_ENVIRONMENT, cmd + 10, 1);\n> +\t\t\texpand_path_setenv(GIT_DIR_ENVIRONMENT, cmd + 10, 1);\n> \t\t\tif (envchanged)\n> \t\t\t\t*envchanged = 1;\n> \t\t} else if (!strcmp(cmd, \"--namespace\")) {\n"},{"id":"199879","messageId":"alpine.LNX.2.01.1209250732150.25195@nerf07.vanv.qr","threadId":"31632","inReplyTo":"fdeaa78c0a520ce80e6d2cb09978dab348104eaf.1348491039.git.git@drmicha.warpmail.net","subject":"Re: [RFC/PATCH] git: expand user path in --git-dir","fromName":"Jan Engelhardt","fromEmail":"jengelh@inai.de","sentAt":"2012-09-25T05:33:35Z","receivedAt":"2012-09-25T05:33:35Z","isPatch":true,"sender":{"key":"jengelh@inai.de","avatar":"https://avatars.githubusercontent.com/u/8861948?v=4"},"body":"\nOn Monday 2012-09-24 14:57, Michael J Gruber wrote:\n\n>Currently, all paths in the config file are subject to tilde expansion\n>for user paths while the argument to --git-dir is not expanded, and\n>neither are paths in the environment such as GIT_DIR. From the user\n>perspective, though, the two commands\n>\n>GIT_DIR=~user/foo git command\n>git --git-dir=~user/foo command\n>\n>currently behave differently because in the first case the shell would\n>perform tilde expansion, but not in the second.\n\nIf git uses a standardized option logic (getopt-like) which accepts\nboth '=' and (new argument) for long options, you could easily do\n\n\tgit --git-dir ~user/foo command\n"},{"id":"199884","messageId":"50615CF3.2010802@drmicha.warpmail.net","threadId":"31632","inReplyTo":"alpine.LNX.2.01.1209250732150.25195@nerf07.vanv.qr","subject":"Re: [RFC/PATCH] git: expand user path in --git-dir","fromName":"Michael J Gruber","fromEmail":"git@drmicha.warpmail.net","sentAt":"2012-09-25T07:27:47Z","receivedAt":"2012-09-25T07:27:47Z","isPatch":true,"sender":{"key":"git@grubix.eu","avatar":"https://avatars.githubusercontent.com/u/233215?v=4"},"body":"Jan Engelhardt venit, vidit, dixit 25.09.2012 07:33:\n> \n> On Monday 2012-09-24 14:57, Michael J Gruber wrote:\n> \n>> Currently, all paths in the config file are subject to tilde expansion\n>> for user paths while the argument to --git-dir is not expanded, and\n>> neither are paths in the environment such as GIT_DIR. From the user\n>> perspective, though, the two commands\n>>\n>> GIT_DIR=~user/foo git command\n>> git --git-dir=~user/foo command\n>>\n>> currently behave differently because in the first case the shell would\n>> perform tilde expansion, but not in the second.\n> \n> If git uses a standardized option logic (getopt-like) which accepts\n> both '=' and (new argument) for long options, you could easily do\n> \n> \tgit --git-dir ~user/foo command\n\nOf course, but wouldn't it be even more confusing if tilde expansion \"is\ndone\" for \"--git-dir ~user/foo\" but not \"--git-dir=~user/foo\"?\n\nThat confusion is all bash's \"fault\" since \"is done\" == \"is done by\nbash\" (or not), but still.\n\nMichael\n"}]}