Re: GIT_DIR vs. --git-dir

> 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.