On 07/11/2011 09:47 AM, Richard Heck wrote:
> On 07/11/2011 09:32 AM, Vincent van Ravesteijn wrote:
>>
>>> (i) is certainly fixable, in the sense that we can spawn "git
>>> status" and check the return value, but it is not as easy as looking
>>> for .svn, say.
>>
>> We can just copy-paste the code that git uses itself to detect
>> whether it is in a repo or not ?
>>
> I'm a bit curious how it does this, actually. I mean: In such a way as
> properly to follow symlinks. I run into this kind of problem often.
> E.g., what ".." means seems to vary in a way I do not understand if
> you are in a symlinked directory.
>
For example: Suppose I am in /home/rgheck/; there is symlink from texmf
to files/texmf. (Here files/ is the mount point for an NFS directory.)
If I cd to /home/rgheck/texmf/, then:
(i) "cd .." takes me to /home/rgheck/, as expected
(ii) "ls .." gives me the files in /home/rgheck/files/, as not expected.
It looks like git acts like ls. If you have a symlink in a git repo,
then the symlink is in the repo, but the stuff in the directory to which
it points is not (unless that directory is in the repo anyway).
So this means that we can figure out if we are in a repo by looking up
the tree (apparently, stopping at the mount point, too, if I'm reading
things correctly). But we have to follow the REAL parent, not just strip
off path elements. I do not know how to do that, myself. Maybe the
easiest way would be first to get the real path to whatever directory we
are in, then we can strip off path elements looking for .git. I'm not
sure about how to stop at mount points, though.
Richard
