On Tue, Mar 29, 2016 at 06:53:35AM -0500, Elliott Cable wrote:
> On Tue, Mar 29, 2016 at 6:42 AM, Elliott Cable <[email protected]> wrote:
> > So, I find this behaviour a little strange; I can't determine if it's
> > a subtle bug, or intentionally undefined/‘fuzzy’ behaviour ...
>
> Oh lord, it gets worse ...
>
> $ cd a-repo
> $ git rev-parse --is-inside-work-tree; git rev-parse --is-inside-git-dir
> true
> false
> $ cd .git
> $ git rev-parse --is-inside-work-tree; git rev-parse --is-inside-git-dir
> false
> true
I believe these are working correctly, the .git directory is not part of
the working tree.
> $ export GIT_WORK_TREE="$(git rev-parse --show-toplevel)" # !!!
Did you check the value of GIT_WORK_TREE here? When I try it's the
empty string.
If I set the core.worktree config variable to ".." then rev-parse does
find the working tree correctly. I recall some previous discussion
about this but I can't find it in the list archives from a quick search.
> $ git rev-parse --is-inside-work-tree; git rev-parse --is-inside-git-dir
> true
> false
> $ # !!?!?
>
> So, basically, if `$GIT_WORK_TREE` is set at all, it appears that the
> `rev-parse --is-inside...` flags don't function reliably at all.
If you set GIT_WORK_TREE you're telling Git to override all of the
normal detection logic. What version of Git are you using? When I try
this it says:
fatal: The empty string is not a valid path
If I set GIT_WORK_TREE to the correct value for this repository then it
behaves the same as with the auto-detection logic.
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
