From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Dmitry Gutov Newsgroups: gmane.emacs.bugs Subject: bug#21383: Static revisions in vc-working-revision Date: Sat, 5 Sep 2015 06:08:32 +0300 Message-ID: <55EA5CB0.9070007@yandex.ru> References: <55E41499.5030501@yandex.ru> <55E5094A.3010108@yandex.ru> <55E59487.1050804@yandex.ru> <55E5CA42.1080005@yandex.ru> <55E5DF1A.9010902@yandex.ru> <55E6D426.10105@yandex.ru> <55E89E83.6000501@yandex.ru> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-Trace: ger.gmane.org 1441422563 26500 80.91.229.3 (5 Sep 2015 03:09:23 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sat, 5 Sep 2015 03:09:23 +0000 (UTC) Cc: 21383-done@debbugs.gnu.org, Jonathan H To: Stefan Monnier Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Sat Sep 05 05:09:12 2015 Return-path: Envelope-to: geb-bug-gnu-emacs@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1ZY3qp-0001Ts-62 for geb-bug-gnu-emacs@m.gmane.org; Sat, 05 Sep 2015 05:09:11 +0200 Original-Received: from localhost ([::1]:37024 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZY3qo-0005lN-Oa for geb-bug-gnu-emacs@m.gmane.org; Fri, 04 Sep 2015 23:09:10 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:34541) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZY3ql-0005k6-2Y for bug-gnu-emacs@gnu.org; Fri, 04 Sep 2015 23:09:08 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1ZY3qg-0004Y4-1X for bug-gnu-emacs@gnu.org; Fri, 04 Sep 2015 23:09:06 -0400 Original-Received: from debbugs.gnu.org ([208.118.235.43]:56957) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZY3qf-0004Xn-Uz for bug-gnu-emacs@gnu.org; Fri, 04 Sep 2015 23:09:01 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.80) (envelope-from ) id 1ZY3qf-0003oD-Ku for bug-gnu-emacs@gnu.org; Fri, 04 Sep 2015 23:09:01 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Dmitry Gutov Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sat, 05 Sep 2015 03:09:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 21383 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: Original-Received: via spool by 21383-done@debbugs.gnu.org id=D21383.144142251914613 (code D ref 21383); Sat, 05 Sep 2015 03:09:01 +0000 Original-Received: (at 21383-done) by debbugs.gnu.org; 5 Sep 2015 03:08:39 +0000 Original-Received: from localhost ([127.0.0.1]:49167 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1ZY3qI-0003nc-Bs for submit@debbugs.gnu.org; Fri, 04 Sep 2015 23:08:38 -0400 Original-Received: from mail-wi0-f172.google.com ([209.85.212.172]:34293) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1ZY3qG-0003nU-DH for 21383-done@debbugs.gnu.org; Fri, 04 Sep 2015 23:08:36 -0400 Original-Received: by wicfx3 with SMTP id fx3so38532962wic.1 for <21383-done@debbugs.gnu.org>; Fri, 04 Sep 2015 20:08:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=sender:subject:to:references:cc:from:message-id:date:user-agent :mime-version:in-reply-to:content-type:content-transfer-encoding; bh=DwJaZGqgUqvN9AjQu2fAIqeEaK7KnVIxVEfBmiiyrf8=; b=musM3/FJpMhShfoo4c14Kkyc7n45MjrF1PVr7H6EU+52704aNkylh0tZLgyghSPrei uo7nr8ydpevqI+/N+2e0demXNjHtmNiuNM8QrUYWF4dHZYeUJvtypZyTM1PgzU7HqqtL AsGP3RPfWodZekHY6/aNly1u+Baa+wJ+STZ4cum9lrtuiO6xJwxenOXDcoaAMz+BHNoF 8TbgHjNNetlVBn3WmFwVBpLrFkTb6kG+HS8uciPHwWiZU+s1I/pwwA4BD21RydiRMTu5 QuXZR23uv6XDBNfInsLCXrnE+4/T5U0wiqfljJhs2+4/nCPptjUcDErQ028xKN6fn9UV SzAA== X-Received: by 10.180.10.8 with SMTP id e8mr12763967wib.22.1441422515867; Fri, 04 Sep 2015 20:08:35 -0700 (PDT) Original-Received: from [10.9.0.103] (nat.webazilla.com. [78.140.128.228]) by smtp.googlemail.com with ESMTPSA id du6sm7694685wib.24.2015.09.04.20.08.34 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 04 Sep 2015 20:08:34 -0700 (PDT) User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:40.0) Gecko/20100101 Thunderbird/40.0 In-Reply-To: X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list X-detected-operating-system: by eggs.gnu.org: GNU/Linux 3.x X-Received-From: 208.118.235.43 X-BeenThere: bug-gnu-emacs@gnu.org List-Id: "Bug reports for GNU Emacs, the Swiss army knife of text editors" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Original-Sender: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.bugs:106163 Archived-At: On 09/04/2015 05:20 AM, Stefan Monnier wrote: > So I don't think we can drop the FILE argument, but we can make it > clear that it's OK to ignore it and use default-directory instead. That, by itself, would be an easy change to make. In the docs. > That's why I'm suggesting to pass FILE as a relative file-name. > It is slightly delicate, tho, since the vc-root for default-directory > may actually be different from the vc-root for (expand-file-name > ). My problem with that is passing a relative file-name doesn't help any backend, in any way: if the file-name is relative to the current default-directory, vc-git-* will continue behaving exactly the same, whether default-directory is the root, or simply the current directory. If the file-name is relative to some other directory that the current (from vc-git's standpoint) default-directory, then vc-git operations will simply fail. Either way, the onus is on vc-working-revision and other generic functions to bind default-directory. And as long as default-directory is right, the file-names might as well stay absolute. > I don't think we should impose a constraint that default-directory is > vc-root. So, backends like Git may still have to find the vc-root > from the default-directory (tho in many cases, the underlying executable > will do that for us). If default-directory is outside of $git_repo, passing a path to a file inside it to 'git status' doesn't work. So someone still needs to bind default-directory to somewhere inside it. However - this looks like the easiest solution - binding it to (file-name-directory file) should work well enough for backends with either type of revision granularity. At least as long as the backend program can be called in any subdirectory of the repository.