GIT_DIR vs. --git-dir

> [mjg@localhost ~]$ GIT_DIR=~/.githome git rev-parse --show-toplevel
> /home/mjg
>
> [mjg@localhost ~]$ git --git-dir=~/.githome rev-parse --show-toplevel
> fatal: Not a git repository: '~/.githome'
>
> Huh?

> Ok, so most users probably would not try further and blame git, but:
>
> [mjg@localhost ~]$ git --git-dir=/home/mjg/.githome rev-parse
> --show-toplevel
> /home/mjg
>
> (All this is with core.worktree set to /home/mjg.)
>
> So, while I do understand that we don't expand '~' in any of these cases
> and it's only a matter of bash tilde expansion kicking in or not, we
> might want to do something about it. (--git-dir=$HOME/.githome gets
> expanded, as well, and --git-dir=.githome works from the appropriate cwd
> only).

> On Mon, Sep 24, 2012 at 2:19 PM, Michael J Gruber
> <git@drmicha.warpmail.net> wrote:
>> [mjg@localhost ~]$ GIT_DIR=~/.githome git rev-parse --show-toplevel
>> /home/mjg
>>
>> [mjg@localhost ~]$ git --git-dir=~/.githome rev-parse --show-toplevel
>> fatal: Not a git repository: '~/.githome'
>>
>> Huh?
> 
> The message looks pretty clear to me that ~ is not expanded.

> 
>> Ok, so most users probably would not try further and blame git, but:
>>
>> [mjg@localhost ~]$ git --git-dir=/home/mjg/.githome rev-parse
>> --show-toplevel
>> /home/mjg
>>
>> (All this is with core.worktree set to /home/mjg.)
>>
>> So, while I do understand that we don't expand '~' in any of these cases
>> and it's only a matter of bash tilde expansion kicking in or not, we
>> might want to do something about it. (--git-dir=$HOME/.githome gets
>> expanded, as well, and --git-dir=.githome works from the appropriate cwd
>> only).
> 
> "~" is a shell feature. Know your shell. If we make an exception for
> --git-dir, we might have to support --blahblah=~/somewhere. That's a
> lot of changes and we might mistakenly over-expand something. Users
> running git on cmd.exe may get surprised that "~" is expanded. We
> could print an advice "did you mean $HOME/.githome?". That could still
> be a lot of changes, but it's no-op so less worries of breaking
> something. I prefer doing nothing in this case.

> On Mon, Sep 24, 2012 at 2:57 PM, Michael J Gruber
> <git@drmicha.warpmail.net> wrote:
>> It might be difficult to implement, but I'm sorry I can't follow the
>> argumentation above at all; it's not based on what we do in other places
>> and other cases.
> 
> My point is, what's so special about --git-dir? what about
> --work-tree, or "commit -F path"? It's hard to draw a line there.

> Config files are a special case, because git is the only one that
> reads the file. "~" expansion depends on shell setting. If users turn
> it off, they may be surprised that "~foo" is turned to /home/foo while
> they really mean "~foo". Warning is the only sensible thing we could
> do.

> Currently, all paths in the config file are subject to tilde expansion
> for user paths while the argument to --git-dir is not expanded, and
> neither are paths in the environment such as GIT_DIR. From the user
> perspective, though, the two commands
> 
> GIT_DIR=~user/foo git command
> git --git-dir=~user/foo command
> 
> currently behave differently because in the first case the shell would
> perform tilde expansion, but not in the second. Also, one may argue that
> specifying '--git-dir=' is like specifying a config variable (which
> cannot exist for this purpose).
> 
> Thus, make arguments to '--git-dir' undergo tilde expansion.
> ---
> So, here's a simple patch implementing tilde expansion for --git-dir. It passes
> all tests. It's done doing the expansion on the setting side.
> 
> Alternatively, one might do it on the getting side, i.e. when reading GIT_DIR,
> so that paths passed directly through the environment undergo tilde expansion
> as well. We don't do this for any environment variable yet, so I didn't go
> that far.

> On Mon, Sep 24, 2012 at 02:57:20PM +0200, Michael J Gruber wrote:
> 
>> Currently, all paths in the config file are subject to tilde expansion
>> for user paths while the argument to --git-dir is not expanded, and
>> neither are paths in the environment such as GIT_DIR. From the user
>> perspective, though, the two commands
>>
>> GIT_DIR=~user/foo git command
>> git --git-dir=~user/foo command
>>
>> currently behave differently because in the first case the shell would
>> perform tilde expansion, but not in the second. Also, one may argue that
>> specifying '--git-dir=' is like specifying a config variable (which
>> cannot exist for this purpose).
>>
>> Thus, make arguments to '--git-dir' undergo tilde expansion.
>> ---
>> So, here's a simple patch implementing tilde expansion for --git-dir. It passes
>> all tests. It's done doing the expansion on the setting side.
>>
>> Alternatively, one might do it on the getting side, i.e. when reading GIT_DIR,
>> so that paths passed directly through the environment undergo tilde expansion
>> as well. We don't do this for any environment variable yet, so I didn't go
>> that far.
> 
> Keep in mind that every layer of expansion you add is a layer of quoting
> somebody else must do in order to pass through certain paths.  I will
> admit that putting a "~" into a path is relatively uncommon, but this
> patch is a regression for anybody who does so with --git-dir (they will
> now need to quote the "~" against not just their shell, but against
> git). Expanding environment variables like GIT_DIR means that we would
> also need to quote things we put into GIT_DIR.

> Currently, all paths in the config file are subject to tilde expansion
> for user paths while the argument to --git-dir is not expanded, and
> neither are paths in the environment such as GIT_DIR. From the user
> perspective, though, the two commands
>
> GIT_DIR=~user/foo git command
> git --git-dir=~user/foo command
>
> currently behave differently because in the first case the shell would
> perform tilde expansion, but not in the second. Also, one may argue that
> specifying '--git-dir=' is like specifying a config variable (which
> cannot exist for this purpose).
>
> Thus, make arguments to '--git-dir' undergo tilde expansion.
> ---
> So, here's a simple patch implementing tilde expansion for --git-dir. It passes
> all tests. It's done doing the expansion on the setting side.

> Alternatively, one might do it on the getting side, i.e. when reading GIT_DIR,
> so that paths passed directly through the environment undergo tilde expansion
> as well. We don't do this for any environment variable yet, so I didn't go
> that far.
>
> Signed-off-by: Michael J Gruber <git@drmicha.warpmail.net>
> ---
>  git.c | 20 ++++++++++++++++++--
>  1 file changed, 18 insertions(+), 2 deletions(-)
>
> diff --git a/git.c b/git.c
> index 8788b32..35e8011 100644
> --- a/git.c
> +++ b/git.c
> @@ -64,6 +64,22 @@ static void commit_pager_choice(void) {
>  	}
>  }
>  
> +static int expand_path_setenv(const char *name, const char *value, int overwrite)
> +{
> +	int ret;
> +	const char *expanded;
> +
> +	if (!value)
> +		return setenv(name, value, overwrite);
> +
> +	expanded = expand_user_path(value);
> +	if (!expanded)
> +		die("Failed to expand user dir in: '%s'", value);

> +	ret = setenv(name, expanded, overwrite);
> +	free((void *)expanded);
> +	return ret;
> +}
> +
>  static int handle_options(const char ***argv, int *argc, int *envchanged)
>  {
>  	const char **orig_argv = *argv;
> @@ -117,13 +133,13 @@ static int handle_options(const char ***argv, int *argc, int *envchanged)
>  				fprintf(stderr, "No directory given for --git-dir.\n" );
>  				usage(git_usage_string);
>  			}
> -			setenv(GIT_DIR_ENVIRONMENT, (*argv)[1], 1);
> +			expand_path_setenv(GIT_DIR_ENVIRONMENT, (*argv)[1], 1);
>  			if (envchanged)
>  				*envchanged = 1;
>  			(*argv)++;
>  			(*argc)--;
>  		} else if (!prefixcmp(cmd, "--git-dir=")) {
> -			setenv(GIT_DIR_ENVIRONMENT, cmd + 10, 1);
> +			expand_path_setenv(GIT_DIR_ENVIRONMENT, cmd + 10, 1);
>  			if (envchanged)
>  				*envchanged = 1;
>  		} else if (!strcmp(cmd, "--namespace")) {

>Currently, all paths in the config file are subject to tilde expansion
>for user paths while the argument to --git-dir is not expanded, and
>neither are paths in the environment such as GIT_DIR. From the user
>perspective, though, the two commands
>
>GIT_DIR=~user/foo git command
>git --git-dir=~user/foo command
>
>currently behave differently because in the first case the shell would
>perform tilde expansion, but not in the second.

> 
> On Monday 2012-09-24 14:57, Michael J Gruber wrote:
> 
>> Currently, all paths in the config file are subject to tilde expansion
>> for user paths while the argument to --git-dir is not expanded, and
>> neither are paths in the environment such as GIT_DIR. From the user
>> perspective, though, the two commands
>>
>> GIT_DIR=~user/foo git command
>> git --git-dir=~user/foo command
>>
>> currently behave differently because in the first case the shell would
>> perform tilde expansion, but not in the second.
> 
> If git uses a standardized option logic (getopt-like) which accepts
> both '=' and (new argument) for long options, you could easily do
> 
> 	git --git-dir ~user/foo command

> Nguyen Thai Ngoc Duy <pclouds@gmail.com> writes:
> 
>> "~" is a shell feature. Know your shell. If we make an exception for
>> --git-dir, we might have to support --blahblah=~/somewhere.
> 
> Correct but not entirely true.
> 
> When we know --git-dir=<path> must name a path, we should be able to
> do better.  See OPT_FILENAME in >parse-optios.h>, for inspiration.
> 
> MJG's patch later in this thread is conceptually OK but I do not
> think it should introduce a "expand and then setenv" helper that
> won't be useful unless the variable is GIT_DIR.  That pattern does
> not appear that often, and smells like a bad API design taste.

> [mjg@localhost ~]$ GIT_DIR=~/.githome git rev-parse --show-toplevel
> /home/mjg
> 
> [mjg@localhost ~]$ git --git-dir=~/.githome rev-parse --show-toplevel
> fatal: Not a git repository: '~/.githome'
> 
> Huh? Ok, so most users probably would not try further and blame git, but:
> 
> [mjg@localhost ~]$ git --git-dir=/home/mjg/.githome rev-parse
> --show-toplevel
> /home/mjg
> 
> (All this is with core.worktree set to /home/mjg.)
> 
> So, while I do understand that we don't expand '~' in any of these cases
> and it's only a matter of bash tilde expansion kicking in or not, we
> might want to do something about it. (--git-dir=$HOME/.githome gets
> expanded, as well, and --git-dir=.githome works from the appropriate cwd
> only).

> On Mon, Sep 24, 2012 at 09:19:27AM +0200, Michael J Gruber wrote:
> 
>> [mjg@localhost ~]$ GIT_DIR=~/.githome git rev-parse --show-toplevel
>> /home/mjg
>>
>> [mjg@localhost ~]$ git --git-dir=~/.githome rev-parse --show-toplevel
>> fatal: Not a git repository: '~/.githome'
>>
>> Huh? Ok, so most users probably would not try further and blame git, but:
>>
>> [mjg@localhost ~]$ git --git-dir=/home/mjg/.githome rev-parse
>> --show-toplevel
>> /home/mjg
>>
>> (All this is with core.worktree set to /home/mjg.)
>>
>> So, while I do understand that we don't expand '~' in any of these cases
>> and it's only a matter of bash tilde expansion kicking in or not, we
>> might want to do something about it. (--git-dir=$HOME/.githome gets
>> expanded, as well, and --git-dir=.githome works from the appropriate cwd
>> only).
> 
> Bash is even weirder than you might think. Try this:
> 
>   $ echo ~/foo
>   /home/peff/foo
> 
>   $ echo arg=~/foo
>   arg=/home/peff/foo
> 
>   $ echo --arg=~/foo
>   --arg=~/foo
> 
> That is, it expands on the right-hand side of an "=" (which, from my
> reading of the bash manual, means it considers it a word split), but
> refuses to expand after an "=" that is part of a long option.
> 
> The first one is definitely correct. It would be convenient for your use
> case to expand the third one, and it logically follows from the second
> one. However, dash does not expand the second one. I'm not sure if this
> is a bug in bash, or simply a grey area where the two shells do not
> agree.
> 
> But it makes me wonder if the world would be better served by a bash
> option to always enable tilde expansion after an "=". That would solve
> your issue, and it would make the same feature work for every other git
> long option, as well as for other programs.

> Bash is even weirder than you might think. Try this:
>
>   $ echo ~/foo
>   /home/peff/foo
>
>   $ echo arg=~/foo
>   arg=/home/peff/foo
>
>   $ echo --arg=~/foo
>   --arg=~/foo