>> You won't notice anything different in the output of course, but the
>> environment will be odd:
>> GIT_DIR=../tmp/./././.git
>> GIT_WORK_TREE=$HOME/tmp
>> 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.
>
> I think this one is in the "if it hurts, don't do it then"
> territory.
I just find it inconsistent: one variable is always straightened
("normalized"), while the other one is or is not, depending on
circumstances
>> 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.
>
> Is that because meta/config does not say where the worktree is?
>
> Again, this smells like "if it hurts, don't do it then", even more
> so than the previous one. Does it help if you add --git-work-tree
> to the command line, too?
I agree this one is on the edge, so wasn't sure. I don't specify
worktree at all, anywhere. And expect Git to guess it to be the
current directory. It does so only if GIT_DIR, whatever it is, ends
with "/.git". What's the logic? When the reader skims through the "man
git-config" page, they'll think that work-tree defaults to "." if no
value was provided. But it's only true if "core.bare" is set to false
--
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