Re: vc-git bug with top-level repositories

[Claus <claus.klingberg@gmail.com>]

So I dug deeper and it seems like the culprit (at least in my
situation) is in the function vc-find-root:

This function is traversing the directory tree for a file upwards to
look for (in our case) the root .git directory. If it finds it, the
file will be treated as under GIT-version control.

As an optimization(?), the following comment describes why traversing
is stopped when the owner of an encountered file/dir changes:

[...]
;; As a heuristic, we stop looking up the hierarchy of
;; directories as soon as we find a directory belonging
;; to another user.  This should save us from looking in
;; things like /net and /afs.  This assumes that all the
;; files inside a project belong to the same user.
[...]

So in my case "c:/work/foo/bar/somefile" had a different owner than
"c:/work/foo/bar" so Emacs stopped looking for .git further upwards
--> no version control enabled.

As a workaround, setting the owner on "c:/work/foo/bar" to be equal to
"somefile" fixed the problem for me.

I'm not yet sure if this is a bug or a feature and will perhaps patch
the code for myself once I've found a better solution (or understand
why checking the owner would make sense - on Windows anyway).

What still bothers me is that I could swear I didn't have this problem
in my last build from July. Strange.... since nobody touched this
particular function since February this year.


Claus



On Mon, Aug 18, 2008 at 10:31 PM, Dan Nicolaescu <dann@ics.uci.edu> wrote:
> Claus <claus.klingberg@gmail.com> writes:
>
>  > > Try to figure out why (vc-git-registered "c:/work/foo/bar/somefile.xml")
>  > > does not return t.
>  >
>  > Fair enough :)
>  >
>  > Well, it seems like vc-git-registered returns t for files in the
>  > top-level git-directory (the directory, where .git resides). It does
>  > however NOT return t for files in subdirectories of where the .git dir
>  > resides.
>
> Please "Try to figure out why"...
>
>  > Any recent changes to vc-git-registered that might have caused this?
>
> No idea.
>