emacs-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: vc-git bug with top-level repositories


From: Eli Zaretskii
Subject: Re: vc-git bug with top-level repositories
Date: Tue, 19 Aug 2008 21:46:35 +0300

> Date: Tue, 19 Aug 2008 13:01:54 +0200
> From: Claus <address@hidden>
> Cc: address@hidden, Dan Nicolaescu <address@hidden>
> 
> 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.
> [...]

This assumption is only valid for Posix platforms...

> 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 this case clearly shows.  I think VC needs to limit this
heuristic to Posix platforms only.

> 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.

Maybe nobody touched that particular function, but I touched
file-attributes and directory-files-and-attributes (on MS-Windows) by
adding to the emulation of `stat' real owner and primary group of the
file, as the NTFS filesystem records them.  Could this be the reason
for the different behavior?




reply via email to

[Prev in Thread] Current Thread [Next in Thread]