Nguyen Thai Ngoc Duy venit, vidit, dixit 24.09.2012 09:41: > On Mon, Sep 24, 2012 at 2:19 PM, Michael J Gruber > <git@xxxxxxxxxxxxxxxxxxxx> 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. ...to you and me, of course, but the point is whether we can be more helpful to most users. > >> 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. First of all, we expand '~' in other cases (basically all config vars) ta) where it's unambiguously a path. And --git-dir really is the sensible version of core.gitdir (which would make no sense, of course). Then, "we" refuse to make "~2" a shorthand for "HEAD~2" in the revision parser because "~2" has a meaning for certain shells in certain situations (depending on your dirstack) and would need to be quoted, so we certainly take into account how the shell behaves. 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. Michael -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html