Since at it, I have discovered a couple more minor things with
this rarely-used option. I'm however a bit wary of stepping on
somebody's nerve with this sort of picking things.. :)


1) an apparent missing "normalize_path(git_dir)", when GIT_DIR is an
absolute path:

don't even need to name the repository anything different, but run this command:

$ cd ~/tmp/
$ git init
$ git --git-dir=$HOME/tmp/../tmp/./././.git --work-tree=$HOME/tmp/../tmp/ status

You won't notice anything different in the output of course, but the
environment will be odd:
Notice how the work-tree has been normalized and git-dir hasn't. It's
kinda hard to imagine when this can lead to an error, but never know.
Would there be objections to fixing this?

2) "git --git-dir=meta status" complains:

$ git --git-dir=meta init
$ git --git-dir=meta status

yells that work-tree isn't setup and denies to run. I'm sure most
people are aware of this. Yet, the "git-config" man page says that if
--git-dir or GIT_DIR is given then work-tree is assumed to be the
current directory. The difference with the actual behaviour is
explained by the fact that when the repository is not named anything
that ends with ".git" then it is considered a bare repository (if no
--work-tree is given), and the work-tree doesn't get setup and thus
the complaint. It maybe a safety precaution, so that Git doesn't
assume that it's at the top of work-tree while it may be actually
somewhere in the middle. But how is it different if the user runs "git
--git-dir=/opt/sparc/src/.git add sccs.c" while still sitting in the
middle of the tree? I can't judge myself which behaviour would be
right here, and ask for an opinion

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

Reply via email to