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 -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
