From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Eli Zaretskii Newsgroups: gmane.emacs.devel Subject: Re: vc-git bug with top-level repositories Date: Wed, 20 Aug 2008 18:51:10 +0300 Message-ID: References: <200808181433.m7IEX8U3028640@sallyv1.ics.uci.edu> <200808181639.m7IGd1kb005968@sallyv1.ics.uci.edu> <200808182031.m7IKVbR7001754@sallyv1.ics.uci.edu> Reply-To: Eli Zaretskii NNTP-Posting-Host: lo.gmane.org X-Trace: ger.gmane.org 1219247567 6342 80.91.229.12 (20 Aug 2008 15:52:47 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Wed, 20 Aug 2008 15:52:47 +0000 (UTC) Cc: dann@ics.uci.edu, ams@gnu.org, claus.klingberg@gmail.com, emacs-devel@gnu.org To: Stefan Monnier Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Wed Aug 20 17:53:40 2008 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([199.232.76.165]) by lo.gmane.org with esmtp (Exim 4.50) id 1KVpzn-0001MZ-B6 for ged-emacs-devel@m.gmane.org; Wed, 20 Aug 2008 17:53:15 +0200 Original-Received: from localhost ([127.0.0.1]:55175 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1KVpyp-0000vC-VR for ged-emacs-devel@m.gmane.org; Wed, 20 Aug 2008 11:52:16 -0400 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1KVpyj-0000uV-Jg for emacs-devel@gnu.org; Wed, 20 Aug 2008 11:52:09 -0400 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1KVpyg-0000ss-Ou for emacs-devel@gnu.org; Wed, 20 Aug 2008 11:52:07 -0400 Original-Received: from [199.232.76.173] (port=53596 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1KVpyg-0000sp-4S for emacs-devel@gnu.org; Wed, 20 Aug 2008 11:52:06 -0400 Original-Received: from mtaout5.012.net.il ([84.95.2.13]:22410) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1KVpyZ-00015X-Pn; Wed, 20 Aug 2008 11:52:00 -0400 Original-Received: from HOME-C4E4A596F7 ([84.229.211.50]) by i_mtaout5.012.net.il (HyperSendmail v2004.12) with ESMTPA id <0K5W00DD1PE30R30@i_mtaout5.012.net.il>; Wed, 20 Aug 2008 18:51:39 +0300 (IDT) In-reply-to: X-012-Sender: halo1@inter.net.il X-detected-kernel: by monty-python.gnu.org: Solaris 9.1 X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.devel:102727 Archived-At: > From: Stefan Monnier > Cc: Claus , 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.