GNU bug report logs - #21383
Static revisions in vc-working-revision

Previous Next

Full log

Message #85 received at 21383-done <at> debbugs.gnu.org (full text, mbox):

From: Stefan Monnier <monnier <at> iro.umontreal.ca>
To: Dmitry Gutov <dgutov <at> yandex.ru>
Cc: 21383-done <at> debbugs.gnu.org, Jonathan H <pythonnut <at> gmail.com>
Subject: Re: bug#21383: Static revisions in vc-working-revision
Date: Sat, 05 Sep 2015 11:12:58 -0400

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

[ By and large, a file name that's not relative to default-directory is
  a dead file name.  ]

Yes, the file names would be relative to default-directory.

> functions to bind default-directory. And as long as default-directory is
> right, the file-names might as well stay absolute.

But that means we pass redundant info, and that's only acceptable if we
can make reasonably sure that the two copies are in sync.
Using relative file names we don't have the problem of keeping duplicate
info in sync.

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

No, I think that it's perfectly acceptable to say that the Git branch
used depends solely on default-directory.  So if default-directory is
outside of $git_repo, you get what you asked for.


        Stefan

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.