Re: GIT_DIR vs. --git-dir

[Jeff King <peff@peff.net>]

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.

-Peff