vc-git bug with top-level repositories

vc-git bug with top-level repositories

[Alfred M. Szmidt]

Hi,

if you have git repository in e.g. /foo/.git then vc-mode stops
working.  vc-mode also stops working if you have /.git.

By stops working I mean that vc-mode does not detect that a file is
under VC, so you cannot do vc-print-log, vc-next-action, etc.

Cheers.

Re: vc-git bug with top-level repositories

[Dan Nicolaescu]

"Alfred M. Szmidt" <ams@gnu.org> writes:

  > Hi,
  > 
  > if you have git repository in e.g. /foo/.git then vc-mode stops
  > working.  vc-mode also stops working if you have /.git.
  > 
  > By stops working I mean that vc-mode does not detect that a file is
  > under VC, so you cannot do vc-print-log, vc-next-action, etc.

A git repository in /foo/.git works fine for me with emacs from CVS head
and EMACS_22_BRANCH.

What version are you using?  Can you try with emacs -Q?

Re: vc-git bug with top-level repositories

[Claus]

I see this behaviour as well (under Windows):

c:/work/foo/bar/somefile.xml is not recognized to be under GIT vc (but it is).

Whereas $HOME/.emacs is correctly recognized as being under GIT vc.

This used to work in my last build ~ the end of July, but doesn't work
now using:

GNU Emacs 23.0.60.1 (i386-mingw-nt6.0.6001) of 2008-08-17


If I can be of any more help in debugging this, let me know.


Claus


On Mon, Aug 18, 2008 at 4:33 PM, Dan Nicolaescu <dann@ics.uci.edu> wrote:
> "Alfred M. Szmidt" <ams@gnu.org> writes:
>
>  > Hi,
>  >
>  > if you have git repository in e.g. /foo/.git then vc-mode stops
>  > working.  vc-mode also stops working if you have /.git.
>  >
>  > By stops working I mean that vc-mode does not detect that a file is
>  > under VC, so you cannot do vc-print-log, vc-next-action, etc.
>
> A git repository in /foo/.git works fine for me with emacs from CVS head
> and EMACS_22_BRANCH.
>
> What version are you using?  Can you try with emacs -Q?

Re: vc-git bug with top-level repositories

[Dan Nicolaescu]

Claus <claus.klingberg@gmail.com> writes:

  > I see this behaviour as well (under Windows):
  > 
  > c:/work/foo/bar/somefile.xml is not recognized to be under GIT vc (but it is).
  > 
  > Whereas $HOME/.emacs is correctly recognized as being under GIT vc.
  > 
  > This used to work in my last build ~ the end of July, but doesn't work
  > now using:
  > 
  > GNU Emacs 23.0.60.1 (i386-mingw-nt6.0.6001) of 2008-08-17
  > 
  > 
  > If I can be of any more help in debugging this, let me know.

Try to figure out why (vc-git-registered "c:/work/foo/bar/somefile.xml")
does not return t.


  > Claus
  > 
  > 
  > On Mon, Aug 18, 2008 at 4:33 PM, Dan Nicolaescu <dann@ics.uci.edu> wrote:
  > > "Alfred M. Szmidt" <ams@gnu.org> writes:
  > >
  > >  > Hi,
  > >  >
  > >  > if you have git repository in e.g. /foo/.git then vc-mode stops
  > >  > working.  vc-mode also stops working if you have /.git.
  > >  >
  > >  > By stops working I mean that vc-mode does not detect that a file is
  > >  > under VC, so you cannot do vc-print-log, vc-next-action, etc.
  > >
  > > A git repository in /foo/.git works fine for me with emacs from CVS head
  > > and EMACS_22_BRANCH.
  > >
  > > What version are you using?  Can you try with emacs -Q?

Re: vc-git bug with top-level repositories

[Claus]

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

E.g. in a git-repository in c:/work/foo/ a file c:/work/foo/myfile.txt
is recognized, but c:/work/foo/bar/myotherfile.txt is not.

".git" resides in c:/work/foo ony, naturally.


Any recent changes to vc-git-registered that might have caused this?


HTH,
Claus



On Mon, Aug 18, 2008 at 6:39 PM, Dan Nicolaescu <dann@ics.uci.edu> wrote:
> Claus <claus.klingberg@gmail.com> writes:
>
>  > I see this behaviour as well (under Windows):
>  >
>  > c:/work/foo/bar/somefile.xml is not recognized to be under GIT vc (but it is).
>  >
>  > Whereas $HOME/.emacs is correctly recognized as being under GIT vc.
>  >
>  > This used to work in my last build ~ the end of July, but doesn't work
>  > now using:
>  >
>  > GNU Emacs 23.0.60.1 (i386-mingw-nt6.0.6001) of 2008-08-17
>  >
>  >
>  > If I can be of any more help in debugging this, let me know.
>
> Try to figure out why (vc-git-registered "c:/work/foo/bar/somefile.xml")
> does not return t.
>
>
>  > Claus
>  >
>  >
>  > On Mon, Aug 18, 2008 at 4:33 PM, Dan Nicolaescu <dann@ics.uci.edu> wrote:
>  > > "Alfred M. Szmidt" <ams@gnu.org> writes:
>  > >
>  > >  > Hi,
>  > >  >
>  > >  > if you have git repository in e.g. /foo/.git then vc-mode stops
>  > >  > working.  vc-mode also stops working if you have /.git.
>  > >  >
>  > >  > By stops working I mean that vc-mode does not detect that a file is
>  > >  > under VC, so you cannot do vc-print-log, vc-next-action, etc.
>  > >
>  > > A git repository in /foo/.git works fine for me with emacs from CVS head
>  > > and EMACS_22_BRANCH.
>  > >
>  > > What version are you using?  Can you try with emacs -Q?
>

Re: vc-git bug with top-level repositories

[Dan Nicolaescu]

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.

Re: vc-git bug with top-level repositories

[Claus]

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

Re: vc-git bug with top-level repositories

[Paul R]

On Tue, 19 Aug 2008 13:01:54 +0200, Claus <claus.klingberg@gmail.com> said:
Claus> I'm not yet sure if this is a bug or a feature and will perhaps
Claus> patch the code for myself once I've found a better solution (or
Claus> understand why checking the owner would make sense - on Windows
Claus> anyway).

As an other optimisation, can't we let the VCS itself decide whether
a file is under control or not ? I don't use git, but I guess there is
some way to check it. In mercurial for example, 'hg root' returns the
root of the working directory if it exists, fails otherwise.
Sorry if it has already been discussed.

mes deux centimes
-- 
  Paul

Re: vc-git bug with top-level repositories

[Dan Nicolaescu]

Paul R <paul.r.ml@gmail.com> writes:

  > On Tue, 19 Aug 2008 13:01:54 +0200, Claus <claus.klingberg@gmail.com> said:
  > Claus> I'm not yet sure if this is a bug or a feature and will perhaps
  > Claus> patch the code for myself once I've found a better solution (or
  > Claus> understand why checking the owner would make sense - on Windows
  > Claus> anyway).
  > 
  > As an other optimisation, can't we let the VCS itself decide whether
  > a file is under control or not ? I don't use git, but I guess there is
  > some way to check it. In mercurial for example, 'hg root' returns the
  > root of the working directory if it exists, fails otherwise.
  > Sorry if it has already been discussed.

It intentionally not done that way because, it would be too slow.  The
function in question is run every time a file is opened, and the VC
systems are tried in the order they appear in `vc-handled-backends'
until one matches... 

Re: vc-git bug with top-level repositories

[Alfred M. Szmidt]

     > As an other optimisation, can't we let the VCS itself decide
     > whether a file is under control or not ? I don't use git, but I
     > guess there is some way to check it. In mercurial for example,
     > 'hg root' returns the root of the working directory if it
     > exists, fails otherwise.  Sorry if it has already been
     > discussed.

   It intentionally not done that way because, it would be too slow.
   The function in question is run every time a file is opened, and
   the VC systems are tried in the order they appear in
   `vc-handled-backends' until one matches...

I am not sure I buy this.  You already have to check if a file is
registered or not by executing git.  Doing `git rev-parse --git-dir'
or `git rev-parse --is-inside-git-dir' isn't that much more of a
headache.


And I'd rather have aslow, and correct behaviour than wrong and fast.

Re: vc-git bug with top-level repositories

[Andreas Schwab]

"Alfred M. Szmidt" <ams@gnu.org> writes:

>      > As an other optimisation, can't we let the VCS itself decide
>      > whether a file is under control or not ? I don't use git, but I
>      > guess there is some way to check it. In mercurial for example,
>      > 'hg root' returns the root of the working directory if it
>      > exists, fails otherwise.  Sorry if it has already been
>      > discussed.
>
>    It intentionally not done that way because, it would be too slow.
>    The function in question is run every time a file is opened, and
>    the VC systems are tried in the order they appear in
>    `vc-handled-backends' until one matches...
>
> I am not sure I buy this.  You already have to check if a file is
> registered or not by executing git.

But you only have to do that if you positively know that the file is
inside a working tree of a VCS.

> Doing `git rev-parse --git-dir' or `git rev-parse --is-inside-git-dir'
> isn't that much more of a headache.

That would then have to be run for _every_ file that Emacs is opening.
The check whether a directory is controlled by a VCS should be as fast
as possible.

Andreas.

-- 
Andreas Schwab, SuSE Labs, schwab@suse.de
SuSE Linux Products GmbH, Maxfeldstraße 5, 90409 Nürnberg, Germany
PGP key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

Re: vc-git bug with top-level repositories

[Miles Bader]

>> Doing `git rev-parse --git-dir' or `git rev-parse --is-inside-git-dir'
>> isn't that much more of a headache.
>
> That would then have to be run for _every_ file that Emacs is opening.
> The check whether a directory is controlled by a VCS should be as fast
> as possible.

... and it would have to be done for every vcs supported by Emacs...

As Dan says, there's a reason Emacs does it the way it does.

Running (or at least trying to run) 5-6 external programs, for every
file visited, is not a very nice idea, even if the programs are pretty
fast... :-)

I suppose it is true that if Emacs were to use the "run external
programs to check" method, there are probably various optimizations that
could be done -- e.g. only do it once for the first file visited in any
given directory and assume the resulting status holds for subsequent
files in the same directory.  However I think such optimizations also
require making various assumptions (in this case, for instance, that the
state won't change), and have their own tradeoffs.

-Miles

-- 
Discriminate, v.i. To note the particulars in which one person or thing is,
if possible, more objectionable than another.

Re: vc-git bug with top-level repositories

[Paul R]

On Wed, 20 Aug 2008 11:22:01 +0900, Miles Bader <miles.bader@necel.com> said:
Miles> Running (or at least trying to run) 5-6 external programs, for
Miles> every file visited, is not a very nice idea, even if the
Miles> programs are pretty fast... :-)

How about running them asynchronously ? I mean we don't want find-file
to hang for 2 seconds each time, but OTOH we probably don't mind to
wait a couple of seconds to know VCS information related to the file.

-- 
  Paul

Re: vc-git bug with top-level repositories

[Eli Zaretskii]

> Date: Tue, 19 Aug 2008 13:01:54 +0200
> From: Claus <claus.klingberg@gmail.com>
> Cc: ams@gnu.org, Dan Nicolaescu <dann@ics.uci.edu>
> 
> 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?

Re: vc-git bug with top-level repositories

[Stefan Monnier]

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

Re: vc-git bug with top-level repositories

[Eli Zaretskii]

> From: Stefan Monnier <monnier@iro.umontreal.ca>
> Cc: Claus <claus.klingberg@gmail.com>,  ams@gnu.org,  dann@ics.uci.edu,  emacs-devel@gnu.org
> Date: Wed, 20 Aug 2008 10:34:19 -0400
> 
> >> ;; 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?

Perhaps I misunderstood, but the text above sounds like it assumes
that if /foo/bar/baz is owned by me, but /foo/bar is owned by someone
other than myself, /foo cannot be reasonably owned by me.  This might
be a norm on Posix platforms, where no one except myself will do
anything inside my home directory, but on Windows it is very common to
find exceptions to that rule, because everything is world-readable and
world-writable, unless you take special measures to enforce a security
policies that prevent this.

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

Well, in that case, perhaps you need to add an option to disable this
heuristic, since if someone is unfortunate enough to be in the alleged
0.0001%, she will need a fire escape.

Re: vc-git bug with top-level repositories

[Eli Zaretskii]

[Why personal mail?]

> From: David Kastrup <dak@gnu.org>
> Date: Wed, 20 Aug 2008 18:01:33 +0200
> 
> No.  The assumption is that if /foo/bar is owned by somebody different
> from the owner of /foo/bar/baz, then it is unlikely that /foo/bar/baz is
> part of a version controlled work tree with its root at /foo.
> 
> I think that assumption perfectly reasonable.  I know no version control
> system that makes it reasonably workable to have different users mess
> around in the same VC checkout.

If the ported VC system does not bother to look at native NTFS file
security information (the way we now do in Emacs), then it will
happily let the above situation happen, because it doesn't care about
users.

> The version control systems I know are not backup systems: they don't
> restore file dates (or Make would get confused when rewinding history)
> and don't restore file ownership (which could only be done by root,
> anyway).  Having several people mess around in the same checkout is a
> recipe for disaster.

Not on Windows.

Re: vc-git bug with top-level repositories

[Alfred M. Szmidt]

How about adding an extra check, where we check the write permissions
as well for the user and group?  That is, if the user and the group
the user is member of, cannot write to the .git directory then we stop
traversing...

Re: vc-git bug with top-level repositories

[Stefan Monnier]

> How about adding an extra check, where we check the write permissions
> as well for the user and group?  That is, if the user and the group
> the user is member of, cannot write to the .git directory then we stop
> traversing...

I don't think this will fly: currently VC works even when you're looking
at a project to which you don't have write access, so neither the files
nor the .git might be writable.


        Stefan

Re: vc-git bug with top-level repositories

[Alfred M. Szmidt]

   > How about adding an extra check, where we check the write permissions
   > as well for the user and group?  That is, if the user and the group
   > the user is member of, cannot write to the .git directory then we stop
   > traversing...

   I don't think this will fly: currently VC works even when you're looking
   at a project to which you don't have write access, so neither the files
   nor the .git might be writable.

AFAIK, atleast for git, you must have write access, if you do not you
cannot ceate a lock file.

Re: vc-git bug with top-level repositories

[Stefan Monnier]

>> How about adding an extra check, where we check the write permissions
>> as well for the user and group?  That is, if the user and the group
>> the user is member of, cannot write to the .git directory then we stop
>> traversing...

>    I don't think this will fly: currently VC works even when you're looking
>    at a project to which you don't have write access, so neither the files
>    nor the .git might be writable.

> AFAIK, atleast for git, you must have write access, if you do not you
> cannot ceate a lock file.

So you need write access even just to do things like diff or even
just diff-index?  That's too bad.  So maybe for Git we could use that
refinement of my heuristic, but it wouldn't help for other backends.


        Stefan

Re: vc-git bug with top-level repositories

[Miles Bader]

Stefan Monnier <monnier@iro.umontreal.ca> writes:
>>    I don't think this will fly: currently VC works even when you're looking
>>    at a project to which you don't have write access, so neither the files
>>    nor the .git might be writable.
>
>> AFAIK, atleast for git, you must have write access, if you do not you
>> cannot ceate a lock file.
>
> So you need write access even just to do things like diff or even
> just diff-index?  That's too bad.  So maybe for Git we could use that
> refinement of my heuristic, but it wouldn't help for other backends.

I have no idea what ams is talking about here -- operations like
log-viewing and diffing seem to work just fine in git without write
access.

-Miles

-- 
We live, as we dream -- alone....

Re: vc-git bug with top-level repositories

[Alfred M. Szmidt]

   >> How about adding an extra check, where we check the write permissions
   >> as well for the user and group?  That is, if the user and the group
   >> the user is member of, cannot write to the .git directory then we stop
   >> traversing...

   >    I don't think this will fly: currently VC works even when you're looking
   >    at a project to which you don't have write access, so neither the files
   >    nor the .git might be writable.

   > AFAIK, atleast for git, you must have write access, if you do not you
   > cannot ceate a lock file.

   So you need write access even just to do things like diff or even
   just diff-index?  That's too bad.  So maybe for Git we could use that
   refinement of my heuristic, but it wouldn't help for other backends.

I think for git diff you do not need write permissions, since that
doesn't need to be atomic.  I know that for some commands you need
write access (git status comes to mind).

Re: vc-git bug with top-level repositories

[Stefan Monnier]

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

> Perhaps I misunderstood, but the text above sounds like it assumes
> that if /foo/bar/baz is owned by me, but /foo/bar is owned by someone
> other than myself, /foo cannot be reasonably owned by me.

I see.  No it doesn't assume any such thing (this assumption is also
invalid under Posix).  It only assumes that a given checkout of
a project is made of files entirely owned by a single user.

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

> Well, in that case, perhaps you need to add an option to disable this
> heuristic, since if someone is unfortunate enough to be in the alleged
> 0.0001%, she will need a fire escape.

Might be.  I'd still like to know how the OP ended up in this situation,


        Stefan

Re: vc-git bug with top-level repositories

[Alfred M. Szmidt]

   > Well, in that case, perhaps you need to add an option to disable this
   > heuristic, since if someone is unfortunate enough to be in the alleged
   > 0.0001%, she will need a fire escape.

   Might be.  I'd still like to know how the OP ended up in this situation,

I ended up not using vc-mode, but using the command line.  A major
pain.

Re: vc-git bug with top-level repositories

[Stefan Monnier]

>> Well, in that case, perhaps you need to add an option to disable this
>> heuristic, since if someone is unfortunate enough to be in the alleged
>> 0.0001%, she will need a fire escape.

>    Might be.  I'd still like to know how the OP ended up in this situation,

> I ended up not using vc-mode, but using the command line.  A major
> pain.

That explains how you worked around VC's limitation, but I'd be
interested to hear about how you ended up in a state where you bumped
into VC's limitation.  I.e. how come your /foo/bar/ is owned by
a different user than /foo/ even though they're both part of the same
Git tree?


        Stefan

Re: vc-git bug with top-level repositories

[Mathias Megyei]

[Sorry, I forgot to CC emacs-devel in the previous mail]

On Thu, 2008-08-28 at 11:52 -0400, Stefan Monnier wrote:
> >> That explains how you worked around VC's limitation, but I'd be
> >> interested to hear about how you ended up in a state where you bumped
> >> into VC's limitation.  I.e. how come your /foo/bar/ is owned by
> >> a different user than /foo/ even though they're both part of the same
> >> Git tree?
> 
> > I'm not the OP but this will be the case in the workflow I'm
> > currently working on.
> > Two users will work in the same Git worktree.
> 
> Care to explain why it's done this way?

We use this workflow in the layout generation process within the ASIC
development. Layout generation takes long time, often 3 or more month.
Two (or more) people are working together in the same tree on the same
database.
We have worked this way for years without any VCS. Now we introduce
Git for the layout generation process too. We will put the source code
(scripts, tool setup files, "design constraints", etc) under version
control.  

> > User A creates the worktree /foo and works in the directory /foo/adir.
> > User B works in the directory /foo/bdir.
> > Both have umask 0002.
> 
> I think VC will still work fine as long as the users don't create new
> directories.  But admittedly, it's brittle.

The users will create new directories, e.g. to try a different approach
with another set of scripts and alternative constraints.

IIUC the problem is, that Emacs cannot detect reliably which VCS is
being used.
Couldn't we tell Emacs by setting a variable which VCS we are using?
Because we don't plan to use any other VCS than Git I could add the
necessary code to the company wide site-start.el file.
I could even set a variable with the path to the Git repository.

Mathias

Re: vc-git bug with top-level repositories

[Claus]

Hi Mathias,

On Thu, Aug 28, 2008 at 9:19 PM, Mathias Megyei <mathias@mnet-mail.de> wrote:
>[...]
> Couldn't we tell Emacs by setting a variable which VCS we are using?
> Because we don't plan to use any other VCS than Git I could add the
> necessary code to the company wide site-start.el file.
> I could even set a variable with the path to the Git repository.
>

You can at least limit the backends Emacs is looking for by setting
"vc-handled-backends". I did this in my .emacs as soon as I learned
that Emacs otherwise scans for 6(?) possible backends each time you
open a file!

(setq vc-handled-backends '(SVN Git))

...since I have GIT and Subversion installed on my machine.

HTH,
Claus

Re: vc-git bug with top-level repositories

[Stefan Monnier]

> We use this workflow in the layout generation process within the ASIC
> development. Layout generation takes long time, often 3 or more month.
> Two (or more) people are working together in the same tree on the same
> database.
> We have worked this way for years without any VCS. Now we introduce
> Git for the layout generation process too. We will put the source code
> (scripts, tool setup files, "design constraints", etc) under version
> control.  

I've changed the code so that ownership changes are not taken into
account any more, so mixed-ownership within a single project should work
fine in VC now.


        Stefan

Re: vc-git bug with top-level repositories

[Mathias Megyei]

[-- Attachment #1: Type: text/plain, Size: 766 bytes --]

On Sat, 2008-10-25 at 11:20 -0400, Stefan Monnier wrote:

> > We use this workflow in the layout generation process within the ASIC
> > development. Layout generation takes long time, often 3 or more month.
> > Two (or more) people are working together in the same tree on the same
> > database.
> > We have worked this way for years without any VCS. Now we introduce
> > Git for the layout generation process too. We will put the source code
> > (scripts, tool setup files, "design constraints", etc) under version
> > control.  
> 
> I've changed the code so that ownership changes are not taken into
> account any more, so mixed-ownership within a single project should work
> fine in VC now.

I've briefly tested this and it works as expected.

Thanks,

Mathias

[-- Attachment #2: Type: text/html, Size: 1069 bytes --]

Re: vc-git bug with top-level repositories

[Alfred M. Szmidt]

   >> Well, in that case, perhaps you need to add an option to disable this
   >> heuristic, since if someone is unfortunate enough to be in the alleged
   >> 0.0001%, she will need a fire escape.

   >    Might be.  I'd still like to know how the OP ended up in this situation,

   > I ended up not using vc-mode, but using the command line.  A
   > major pain.

   That explains how you worked around VC's limitation, but I'd be
   interested to hear about how you ended up in a state where you
   bumped into VC's limitation.  I.e. how come your /foo/bar/ is owned
   by a different user than /foo/ even though they're both part of the
   same Git tree?

In this case, the directory was in /, / is always owned by root, and
/.git was owned by ams.  I suspect this only crops up in system wide
git trees, like /etc is owned by root, and then you have another user
create /etc/.git to manage /etc.

Re: vc-git bug with top-level repositories

[Stefan Monnier]

> In this case, the directory was in /, / is always owned by root, and
> /.git was owned by ams.  I suspect this only crops up in system wide
> git trees, like /etc is owned by root, and then you have another user
> create /etc/.git to manage /etc.

The owner of the .git administrative directory does not affect VC's
operation, AFAIK.


        Stefan

Re: vc-git bug with top-level repositories

[Alfred M. Szmidt]

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

Thank you for doing this.

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

I think that the optimisation as is, is a bug.  But not the gist of
it.  If the test is just to see if it is a git repo, then we can be
lazy, and let git figure it out for us; executing `git status' will
return non-zero for a git repo.

In either case, I think the current code is wrong, you might have a
shared repository among users, the initial creator is not the
commiter.

Re: vc-git bug with top-level repositories

[Alfred M. Szmidt]

     > if you have git repository in e.g. /foo/.git then vc-mode stops
     > working.  vc-mode also stops working if you have /.git.
     > 
     > By stops working I mean that vc-mode does not detect that a file is
     > under VC, so you cannot do vc-print-log, vc-next-action, etc.

   A git repository in /foo/.git works fine for me with emacs from CVS head
   and EMACS_22_BRANCH.

   What version are you using?  Can you try with emacs -Q?

# emacs --version
GNU Emacs 23.0.60.1
[...]

From CVS head 2008-08-17.

Same behaviour with -Q.

Re: vc-git bug with top-level repositories

[Dan Nicolaescu]

"Alfred M. Szmidt" <ams@gnu.org> writes:

  >      > if you have git repository in e.g. /foo/.git then vc-mode stops
  >      > working.  vc-mode also stops working if you have /.git.
  >      > 
  >      > By stops working I mean that vc-mode does not detect that a file is
  >      > under VC, so you cannot do vc-print-log, vc-next-action, etc.
  > 
  >    A git repository in /foo/.git works fine for me with emacs from CVS head
  >    and EMACS_22_BRANCH.
  > 
  >    What version are you using?  Can you try with emacs -Q?
  > 
  > # emacs --version
  > GNU Emacs 23.0.60.1
  > [...]
  > 
  > >From CVS head 2008-08-17.
  > 
  > Same behaviour with -Q.

Then please try to debug vc-git-registered and find out why it returns
nil for files that are under git.