{"thread":{"id":"47838","subject":"[BUG] git init doesn't respect `--template` like configuration variable init.templateDir and $GIT_TEMPLATE_DIR","startedAt":"2018-02-14T10:11:01Z","lastAt":"2018-02-23T10:11:54Z","messageCount":11,"participants":["Doron Behar","Nguyễn Thái Ngọc Duy","Jeff King","Junio C Hamano","Ævar Arnfjörð Bjarmason","Duy Nguyen"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"339267","messageId":"20180214101019.gaenosifgq3wx2nm@NUC.localdomain","threadId":"47838","inReplyTo":null,"subject":"[BUG] git init doesn't respect `--template` like configuration variable init.templateDir and $GIT_TEMPLATE_DIR","fromName":"Doron Behar","fromEmail":"doron.behar@gmail.com","sentAt":"2018-02-14T10:10:19Z","receivedAt":"2018-02-14T10:11:01Z","isPatch":false,"sender":{"key":"doron.behar@gmail.com","avatar":null},"body":"The title says it all.\n\nIf I run `git init --template=~/path/to/my/template` I get the following\nmessage:\n\n\twarning: templates not found ~/path/to/my/template\n\nBut, if I run:\n\n\t$ env GIT_TEMPLATE_DIR=~/path/to/my/template git init\n\nI don't get a warning and the template is used just fine.\n\nIf I configure the configuration variable `init.templateDir` to\n`~/path/to/my/template` and run `git init` I don't get a warning and the\ntemplate is used just fine.\n\n\n"},{"id":"339269","messageId":"20180214105149.28896-1-pclouds@gmail.com","threadId":"47838","inReplyTo":"20180214101019.gaenosifgq3wx2nm@NUC.localdomain","subject":"[PATCH 1/2] parse-options: expand $HOME on filename options","fromName":"Nguyễn Thái Ngọc Duy","fromEmail":"pclouds@gmail.com","sentAt":"2018-02-14T10:51:48Z","receivedAt":"2018-02-14T10:52:03Z","isPatch":true,"sender":{"key":"pclouds@gmail.com","avatar":"https://avatars.githubusercontent.com/u/720?v=4"},"body":"When you specify \"--path ~/foo\", the shell will automatically expand\n~/foo to $HOME/foo before it's passed to git. The expansion is not done\non \"--path=~/foo\". An experienced user sees the difference but it could\nstill be confusing for others (especially when tab-completion still\nworks on --path=~/foo).\n\nSupport $HOME expansion for all filename options. There are about seven\nof them.\n\nSigned-off-by: Nguyễn Thái Ngọc Duy \n---\n parse-options.c | 9 ++++++---\n 1 file changed, 6 insertions(+), 3 deletions(-)\n\ndiff --git a/parse-options.c b/parse-options.c\nindex d265a756b5..c33f14c74e 100644\n--- a/parse-options.c\n+++ b/parse-options.c\n@@ -38,10 +38,13 @@ static int get_arg(struct parse_opt_ctx_t *p, const struct option *opt,\n \n static void fix_filename(const char *prefix, const char **file)\n {\n-\tif (!file || !*file || !prefix || is_absolute_path(*file)\n-\t || !strcmp(\"-\", *file))\n+\tif (!file || !*file || is_absolute_path(*file) ||\n+\t !strcmp(\"-\", *file))\n \t\treturn;\n-\t*file = prefix_filename(prefix, *file);\n+\tif (**file == '~')\n+\t\t*file = expand_user_path(*file, 0);\n+\telse if (prefix)\n+\t\t*file = prefix_filename(prefix, *file);\n }\n \n static int opt_command_mode_error(const struct option *opt,\n-- \n2.16.1.435.g8f24da2e1a\n\n"},{"id":"339270","messageId":"20180214105149.28896-2-pclouds@gmail.com","threadId":"47838","inReplyTo":"20180214105149.28896-1-pclouds@gmail.com","subject":"[PATCH 2/2] init-db: change --template type to OPTION_FILENAME","fromName":"Nguyễn Thái Ngọc Duy","fromEmail":"pclouds@gmail.com","sentAt":"2018-02-14T10:51:49Z","receivedAt":"2018-02-14T10:52:07Z","isPatch":true,"sender":{"key":"pclouds@gmail.com","avatar":"https://avatars.githubusercontent.com/u/720?v=4"},"body":"OPTION_FILENAME has some magic behind the scene, like prefixing which is\nuseless for init-db. The $HOME expansion though does come handy and\nmakes --template more consistent with the rest (both env and config var\nget $HOME expansion).\n\nNoticed-by: Doron Behar \nSigned-off-by: Nguyễn Thái Ngọc Duy \n---\n builtin/init-db.c | 5 +++--\n 1 file changed, 3 insertions(+), 2 deletions(-)\n\ndiff --git a/builtin/init-db.c b/builtin/init-db.c\nindex 68ff4ad75a..d6bd9f19cb 100644\n--- a/builtin/init-db.c\n+++ b/builtin/init-db.c\n@@ -473,8 +473,9 @@ int cmd_init_db(int argc, const char **argv, const char *prefix)\n \tconst char *template_dir = NULL;\n \tunsigned int flags = 0;\n \tconst struct option init_db_options[] = {\n-\t\tOPT_STRING(0, \"template\", &template_dir, N_(\"template-directory\"),\n-\t\t\t\tN_(\"directory from which templates will be used\")),\n+\t\t{ OPTION_FILENAME, 0, \"template\", &template_dir,\n+\t\t\tN_(\"template-directory\"),\n+\t\t\tN_(\"directory from which templates will be used\")},\n \t\tOPT_SET_INT(0, \"bare\", &is_bare_repository_cfg,\n \t\t\t\tN_(\"create a bare repository\"), 1),\n \t\t{ OPTION_CALLBACK, 0, \"shared\", &init_shared_repository,\n-- \n2.16.1.435.g8f24da2e1a\n\n"},{"id":"339277","messageId":"20180214140557.GA27850@sigill.intra.peff.net","threadId":"47838","inReplyTo":"20180214105149.28896-1-pclouds@gmail.com","subject":"Re: [PATCH 1/2] parse-options: expand $HOME on filename options","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2018-02-14T14:05:58Z","receivedAt":"2018-02-14T14:06:04Z","isPatch":true,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Wed, Feb 14, 2018 at 05:51:48PM +0700, Nguyễn Thái Ngọc Duy wrote:\n\n> When you specify \"--path ~/foo\", the shell will automatically expand\n> ~/foo to $HOME/foo before it's passed to git. The expansion is not done\n> on \"--path=~/foo\". An experienced user sees the difference but it could\n> still be confusing for others (especially when tab-completion still\n> works on --path=~/foo).\n> \n> Support $HOME expansion for all filename options. There are about seven\n> of them.\n\nI think this probably makes sense.\n\n> parse-options.c | 9 ++++++---\n> 1 file changed, 6 insertions(+), 3 deletions(-)\n\nShould this be mentioned in the comment documenting OPT_FILENAME()?\n\n> diff --git a/parse-options.c b/parse-options.c\n> index d265a756b5..c33f14c74e 100644\n> --- a/parse-options.c\n> +++ b/parse-options.c\n> @@ -38,10 +38,13 @@ static int get_arg(struct parse_opt_ctx_t *p, const struct option *opt,\n> \n> static void fix_filename(const char *prefix, const char **file)\n> {\n> -\tif (!file || !*file || !prefix || is_absolute_path(*file)\n> -\t || !strcmp(\"-\", *file))\n> +\tif (!file || !*file || is_absolute_path(*file) ||\n> +\t !strcmp(\"-\", *file))\n> \t\treturn;\n> -\t*file = prefix_filename(prefix, *file);\n> +\tif (**file == '~')\n> +\t\t*file = expand_user_path(*file, 0);\n> +\telse if (prefix)\n> +\t\t*file = prefix_filename(prefix, *file);\n> }\n\nI thought at first this needed a final \"else\" clause, because we don't\nassign to *file if we have neither a prefix nor a user-path. But that's\nwhat the callers expect (and we are similarly a noop if we hit the first\nconditional). So this looks right.\n\n-Peff\n"},{"id":"339278","messageId":"20180214140808.GB27850@sigill.intra.peff.net","threadId":"47838","inReplyTo":"20180214105149.28896-2-pclouds@gmail.com","subject":"Re: [PATCH 2/2] init-db: change --template type to OPTION_FILENAME","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2018-02-14T14:08:09Z","receivedAt":"2018-02-14T14:08:30Z","isPatch":true,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Wed, Feb 14, 2018 at 05:51:49PM +0700, Nguyễn Thái Ngọc Duy wrote:\n\n> OPTION_FILENAME has some magic behind the scene, like prefixing which is\n> useless for init-db. The $HOME expansion though does come handy and\n> makes --template more consistent with the rest (both env and config var\n> get $HOME expansion).\n\nYep, makes sense.\n\n> diff --git a/builtin/init-db.c b/builtin/init-db.c\n> index 68ff4ad75a..d6bd9f19cb 100644\n> --- a/builtin/init-db.c\n> +++ b/builtin/init-db.c\n> @@ -473,8 +473,9 @@ int cmd_init_db(int argc, const char **argv, const char *prefix)\n> \tconst char *template_dir = NULL;\n> \tunsigned int flags = 0;\n> \tconst struct option init_db_options[] = {\n> -\t\tOPT_STRING(0, \"template\", &template_dir, N_(\"template-directory\"),\n> -\t\t\t\tN_(\"directory from which templates will be used\")),\n> +\t\t{ OPTION_FILENAME, 0, \"template\", &template_dir,\n> +\t\t\tN_(\"template-directory\"),\n> +\t\t\tN_(\"directory from which templates will be used\")},\n\nIt's a shame we can't use the slightly more readable OPT_FILENAME(), but\nit forces the use of \"file\" for the argument name. I wonder if it really\nought to be OPT_PATH(), and say \"path\", which would work more\nuniversally.\n\nAt any rate, I'm fine with this until somebody feels like fiddling with\nthe macros.\n\n-Peff\n"},{"id":"339308","messageId":"xmqqbmgro2f1.fsf@gitster-ct.c.googlers.com","threadId":"47838","inReplyTo":"20180214140557.GA27850@sigill.intra.peff.net","subject":"Re: [PATCH 1/2] parse-options: expand $HOME on filename options","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2018-02-14T18:24:02Z","receivedAt":"2018-02-14T18:24:12Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Jeff King writes:\n\n>> Support $HOME expansion for all filename options. There are about seven\n>> of them.\n>\n> I think this probably makes sense.\n>\n>> parse-options.c | 9 ++++++---\n>> 1 file changed, 6 insertions(+), 3 deletions(-)\n>\n> Should this be mentioned in the comment documenting OPT_FILENAME()?\n\nPerhaps. I think all mention of \"$HOME expansion\" should be\nreplaced with \"tilde expansion\", though. I first thought we are\nexpanding any environment variable and $HOME is merely an example of\nit when I read the title and the log message, before seeing that the\npatch just adds a call to expand_user_path().\n\nOther than that, looks good. Thanks for a quick enhancement and a\nreview.\n\n>> diff --git a/parse-options.c b/parse-options.c\n>> index d265a756b5..c33f14c74e 100644\n>> --- a/parse-options.c\n>> +++ b/parse-options.c\n>> @@ -38,10 +38,13 @@ static int get_arg(struct parse_opt_ctx_t *p, const struct option *opt,\n>> \n>> static void fix_filename(const char *prefix, const char **file)\n>> {\n>> -\tif (!file || !*file || !prefix || is_absolute_path(*file)\n>> -\t || !strcmp(\"-\", *file))\n>> +\tif (!file || !*file || is_absolute_path(*file) ||\n>> +\t !strcmp(\"-\", *file))\n>> \t\treturn;\n>> -\t*file = prefix_filename(prefix, *file);\n>> +\tif (**file == '~')\n>> +\t\t*file = expand_user_path(*file, 0);\n>> +\telse if (prefix)\n>> +\t\t*file = prefix_filename(prefix, *file);\n>> }\n>\n> I thought at first this needed a final \"else\" clause, because we don't\n> assign to *file if we have neither a prefix nor a user-path. But that's\n> what the callers expect (and we are similarly a noop if we hit the first\n> conditional). So this looks right.\n>\n> -Peff\n"},{"id":"339410","messageId":"87wozffavp.fsf@evledraar.gmail.com","threadId":"47838","inReplyTo":"20180214105149.28896-1-pclouds@gmail.com","subject":"Re: [PATCH 1/2] parse-options: expand $HOME on filename options","fromName":"Ævar Arnfjörð Bjarmason","fromEmail":"avarab@gmail.com","sentAt":"2018-02-14T22:46:02Z","receivedAt":"2018-02-14T22:46:12Z","isPatch":true,"sender":{"key":"avarab@gmail.com","avatar":"https://avatars.githubusercontent.com/u/45301?v=4"},"body":"\nOn Wed, Feb 14 2018, Nguyễn Thái Ngọc Duy jotted:\n\n> When you specify \"--path ~/foo\", the shell will automatically expand\n> ~/foo to $HOME/foo before it's passed to git. The expansion is not done\n> on \"--path=~/foo\". An experienced user sees the difference but it could\n> still be confusing for others (especially when tab-completion still\n> works on --path=~/foo).\n>\n> Support $HOME expansion for all filename options. There are about seven\n> of them.\n>\n> Signed-off-by: Nguyễn Thái Ngọc Duy \n> ---\n> parse-options.c | 9 ++++++---\n> 1 file changed, 6 insertions(+), 3 deletions(-)\n>\n> diff --git a/parse-options.c b/parse-options.c\n> index d265a756b5..c33f14c74e 100644\n> --- a/parse-options.c\n> +++ b/parse-options.c\n> @@ -38,10 +38,13 @@ static int get_arg(struct parse_opt_ctx_t *p, const struct option *opt,\n>\n> static void fix_filename(const char *prefix, const char **file)\n> {\n> -\tif (!file || !*file || !prefix || is_absolute_path(*file)\n> -\t || !strcmp(\"-\", *file))\n> +\tif (!file || !*file || is_absolute_path(*file) ||\n> +\t !strcmp(\"-\", *file))\n> \t\treturn;\n> -\t*file = prefix_filename(prefix, *file);\n> +\tif (**file == '~')\n> +\t\t*file = expand_user_path(*file, 0);\n> +\telse if (prefix)\n> +\t\t*file = prefix_filename(prefix, *file);\n> }\n>\n> static int opt_command_mode_error(const struct option *opt,\n\nOn current versions of git:\n\n (\n mkdir '/tmp/~' &&\n cd /tmp &&\n touch '~/foo' &&\n git init --template=~\n )\n\nWill create a /tmp/.git with a 'foo' file, whereas now it'll expand ~ to\n$HOME. Since this changes the behavior of this and presumably some other\noptions it seems like something we should have a test for.\n\nIn general I'm mildly negative on adding this, for every user like Doron\nwho'll be less confused by a hack like this, you'll have other users\nwho'll be confused about git inexplicably working with ~ in the middle\nof strings, even though;\n\n $ echo git init --template ~/path\n git init --template /home/avar/path\n $ echo git init --template=~/path\n git init --template=~/path\n\nI think it makes more sense to just leave such expansion to the shell,\nand not try to magically expand it after the fact, since it's both\nconfusing (user: why does this work with git and not this other\nprogram?), and as shown above changes existing semantics.\n\nWe'll also be setting ourselves up for more disappointed users who'll\nnotice that e.g. `git clone file://~/path` doesn't work, but `git clone\nfile://$HOME/path` does, requiring more hacks to expand ~ in more\ncodepaths. Will they also expact `git log -G~` to find references to\ntheir homedir in their dotfiles.git?\n\nI think this way lies madness, and it's better to just avoid it.\n\nBut I think that if we're going to keep it it needs some tests & docs to\npoint confused users to.\n"},{"id":"339493","messageId":"xmqq4lmi9k2m.fsf@gitster-ct.c.googlers.com","threadId":"47838","inReplyTo":"87wozffavp.fsf@evledraar.gmail.com","subject":"Re: [PATCH 1/2] parse-options: expand $HOME on filename options","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2018-02-15T18:36:17Z","receivedAt":"2018-02-15T18:36:25Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Ævar Arnfjörð Bjarmason writes:\n\n> In general I'm mildly negative on adding this, for every user like Doron\n> who'll be less confused by a hack like this, you'll have other users\n> who'll be confused about git inexplicably working with ~ in the middle\n> of strings, even though;\n>\n> $ echo git init --template ~/path\n> git init --template /home/avar/path\n> $ echo git init --template=~/path\n> git init --template=~/path\n>\n> I think it makes more sense to just leave such expansion to the shell,\n> and not try to magically expand it after the fact, since it's both\n> confusing (user: why does this work with git and not this other\n> program?), and as shown above changes existing semantics.\n\nThe above certainly is a reasonable argument.\n\n> I think this way lies madness, and it's better to just avoid it.\n"},{"id":"339914","messageId":"CACsJy8BsUsT6iO9_68+rHnZG5B-tcaXZAXR88nh8DgR65zvVKw@mail.gmail.com","threadId":"47838","inReplyTo":"87wozffavp.fsf@evledraar.gmail.com","subject":"Re: [PATCH 1/2] parse-options: expand $HOME on filename options","fromName":"Duy Nguyen","fromEmail":"pclouds@gmail.com","sentAt":"2018-02-22T09:26:11Z","receivedAt":"2018-02-22T09:26:47Z","isPatch":true,"sender":{"key":"pclouds@gmail.com","avatar":"https://avatars.githubusercontent.com/u/720?v=4"},"body":"On Thu, Feb 15, 2018 at 5:46 AM, Ævar Arnfjörð Bjarmason\n wrote:\n> In general I'm mildly negative on adding this, for every user like Doron\n> who'll be less confused by a hack like this, you'll have other users\n> who'll be confused about git inexplicably working with ~ in the middle\n> of strings, even though;\n>\n> $ echo git init --template ~/path\n> git init --template /home/avar/path\n> $ echo git init --template=~/path\n> git init --template=~/path\n\nIf you have a directory named '~', I expect you are already used to\nprefixing it with './' because '~' will be expanded in many places\nwhere you might want to avoid.\n\n> I think it makes more sense to just leave such expansion to the shell,\n> and not try to magically expand it after the fact, since it's both\n> confusing (user: why does this work with git and not this other\n> program?), and as shown above changes existing semantics.\n>\n> We'll also be setting ourselves up for more disappointed users who'll\n> notice that e.g. `git clone file://~/path` doesn't work, but `git clone\n> file://$HOME/path` does, requiring more hacks to expand ~ in more\n> codepaths. Will they also expact `git log -G~` to find references to\n> their homedir in their dotfiles.git?\n>\n> I think this way lies madness, and it's better to just avoid it.\n\nWell. That's a bit extreme, I think if we add this then we handle case\nby case in future when it makes sense, not blindly expanding '~'\neverywhere.\n\nThe problem I have with this --template=~/path is tab-completion\nactually completes the path, which (mis)leads me to think the command\nwill accept '~/' too. But this looks like a bug in git-completion.bash\nthough, it's a bit eager in completing stuff (or maybe it completes\n\"--template ~/path\" and \"--template=~/path\" the same way).\n\nI don't feel strongly about this. I'm OK with dropping these patches\nif people think it's not a good idea (then I will try to fix\ngit-completion.bash not to complete '~' in this case).\n\n> But I think that if we're going to keep it it needs some tests & docs to\n> point confused users to.\n-- \nDuy\n"},{"id":"339922","messageId":"87606pf8kg.fsf@evledraar.gmail.com","threadId":"47838","inReplyTo":"CACsJy8BsUsT6iO9_68+rHnZG5B-tcaXZAXR88nh8DgR65zvVKw@mail.gmail.com","subject":"Re: [PATCH 1/2] parse-options: expand $HOME on filename options","fromName":"Ævar Arnfjörð Bjarmason","fromEmail":"avarab@gmail.com","sentAt":"2018-02-22T13:38:39Z","receivedAt":"2018-02-22T13:38:50Z","isPatch":true,"sender":{"key":"avarab@gmail.com","avatar":"https://avatars.githubusercontent.com/u/45301?v=4"},"body":"\nOn Thu, Feb 22 2018, Duy Nguyen jotted:\n\n> On Thu, Feb 15, 2018 at 5:46 AM, Ævar Arnfjörð Bjarmason\n> wrote:\n>> In general I'm mildly negative on adding this, for every user like Doron\n>> who'll be less confused by a hack like this, you'll have other users\n>> who'll be confused about git inexplicably working with ~ in the middle\n>> of strings, even though;\n>>\n>> $ echo git init --template ~/path\n>> git init --template /home/avar/path\n>> $ echo git init --template=~/path\n>> git init --template=~/path\n>\n> If you have a directory named '~', I expect you are already used to\n> prefixing it with './' because '~' will be expanded in many places\n> where you might want to avoid.\n\nIndeed. I've never had this use-case, just saying if it's being changed\nit makes sense to have a small test for it somewhere.\n\n>> I think it makes more sense to just leave such expansion to the shell,\n>> and not try to magically expand it after the fact, since it's both\n>> confusing (user: why does this work with git and not this other\n>> program?), and as shown above changes existing semantics.\n>>\n>> We'll also be setting ourselves up for more disappointed users who'll\n>> notice that e.g. `git clone file://~/path` doesn't work, but `git clone\n>> file://$HOME/path` does, requiring more hacks to expand ~ in more\n>> codepaths. Will they also expact `git log -G~` to find references to\n>> their homedir in their dotfiles.git?\n>>\n>> I think this way lies madness, and it's better to just avoid it.\n>\n> Well. That's a bit extreme, I think if we add this then we handle case\n> by case in future when it makes sense, not blindly expanding '~'\n> everywhere.\n>\n> The problem I have with this --template=~/path is tab-completion\n> actually completes the path, which (mis)leads me to think the command\n> will accept '~/' too. But this looks like a bug in git-completion.bash\n> though, it's a bit eager in completing stuff (or maybe it completes\n> \"--template ~/path\" and \"--template=~/path\" the same way).\n\nAh I see, so you're doing \"git init --template=~/\".\n\n> I don't feel strongly about this. I'm OK with dropping these patches\n> if people think it's not a good idea (then I will try to fix\n> git-completion.bash not to complete '~' in this case).\n\nI don't feel strongly about it either, just mildly negative on\nintroducing magic that gives you different behavior than shells do by\ndefault.\n\nI wonder if the consistency with the tab completion wouldn't be better\ndone by teaching the tab completion to just expand --template=~/ to\ne.g. --template=/home/duy/.\n\nOn my (Debian) system doing e.g.:\n\n echo $HOME/bin/\n\nWill expand to:\n\n echo /home/avar/bin/\n\nMaybe we could intercept that in the completion and ~ to the value of\n$HOME. It would give completion that did the right thing, without the\nexpectation that ~ is going to be magic in some places and not others.\n\n>> But I think that if we're going to keep it it needs some tests & docs to\n>> point confused users to.\n"},{"id":"340006","messageId":"CACsJy8BqWVh0VY5Ydqez_Kqc-UwWk7YRuJWCUpYhkBU80rKe7w@mail.gmail.com","threadId":"47838","inReplyTo":"87606pf8kg.fsf@evledraar.gmail.com","subject":"Re: [PATCH 1/2] parse-options: expand $HOME on filename options","fromName":"Duy Nguyen","fromEmail":"pclouds@gmail.com","sentAt":"2018-02-23T10:11:18Z","receivedAt":"2018-02-23T10:11:54Z","isPatch":true,"sender":{"key":"pclouds@gmail.com","avatar":"https://avatars.githubusercontent.com/u/720?v=4"},"body":"On Thu, Feb 22, 2018 at 8:38 PM, Ævar Arnfjörð Bjarmason\n wrote:\n> Ah I see, so you're doing \"git init --template=~/\".\n>\n> ...\n>\n> I wonder if the consistency with the tab completion wouldn't be better\n> done by teaching the tab completion to just expand --template=~/ to\n> e.g. --template=/home/duy/.\n>\n> On my (Debian) system doing e.g.:\n>\n> echo $HOME/bin/\n>\n> Will expand to:\n>\n> echo /home/avar/bin/\n>\n> Maybe we could intercept that in the completion and ~ to the value of\n> $HOME.\n\nYeah that's what I had in mind (though I still have no idea if it's\nhard to do). Let's drop this series then. I'll keep this thing\nin my backlog and hopefully will fix it soon. I'll have to read\ngit-completion.bash carefully for another series anyway. And I have a\nfeeling that \"git --completion-helper\" needs to tell\ngit-completion.bash \"this argument takes a path\" before we start to\nexpand stuff.\n-- \nDuy\n"}]}