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: Stefan Monnier
Subject: Re: vc-git bug with top-level repositories
Date: Wed, 20 Aug 2008 10:34:19 -0400
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/23.0.60 (gnu/linux)

>> 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 do not see where is the Posixness of my assumption (presumably
because Posix is basically all I know).  Could you explain?
E.g. the above example works just as well in Posix:

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

The assumption of my heuristic is that all the files in a given project
belong to the same user.  Clearly there's nothing that guarantees it's
always true, but for "programming projects", it's probably true in
99.9999% of the cases.  If the "project" is a complete OS image OTOH,
it's not going to work.

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

Sounds like it.


        Stefan




reply via email to

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