bug#5344: 23.1.91; bug/wish: vc does not honour GIT_DIR / GIT_WORK_TREE environment variables

bug#5344: 23.1.91; bug/wish: vc does not honour GIT_DIR / GIT_WORK_TREE environment variables

[Gregor Zattler]

Dear emacs developers,

I use bare git repositories for version contol of some dotfiles.[1] This
means that the repository ist *not* in a .git directory which is part of
the working directorys hirarchy.  Instead the environment variable
GIT_DIR indicates the location of the repository and the environment
variable GIT_WORK_TREE indicates the working directory.  But in emacs/vc
these dotfiles do not show up as version controlled, even when the emacs
session inherited the correct GIT_* environment variables:

   ~$ export GIT_DIR=~/.fgits/emacs.git
   ~$ export GIT_WORK_TREE="$GIT_DIR/$(git config --get core.worktree)"
   ~$ printenv|grep GIT
   GIT_DIR=/home/grfz/.fgits/emacs.git
   GIT_WORK_TREE=/home/grfz/.fgits/emacs.git/../../

There are several files/directories under ~/.emacs.d, but *no* .git
directory::

   ~$ ls .emacs.d/
   ~/.emacs.d$ ls -A
   _abbrev_defs      _backup  elpa         _emms-history  history
   init.el            _recentf           todo-top
   _abbrev_defs.old  _diary   _emacs.bmk   games          _ido.last
   lisp               _remember_backups  update-org.sh
   auto-save-list    elisp    _emacs_orig  _gnus
   image-dired  .org-id-locations  todo-do

There is also no ~/.git

   ~/$ ls -l ~/.git
   ls: cannot access /home/grfz/.git: No such file or directory

but git works fine:

   cd ~/.emacs.d

   ~/.emacs.d$ git status
   # On branch master
   # Changed but not updated:
   #   (use "git add <file>..." to update what will be committed)
   #   (use "git checkout -- <file>..." to discard changes in
   #   working directory)
   #
   #       modified:   init.el
   #
   no changes added to commit (use "git add" and/or "git commit -a")

Or:

   ~/.emacs.d$ git log -n 1
   commit ffa6f03211b7234533d060886614b96ea59c30f0
   Author: Gregor Zattler <telegraph@gmx.net>
   Date:   Thu Jan 7 22:38:23 2010 +0100
   
       new german aspell directory name; show max buffer size; minor
       changes
   

This are the files in ~/.emacs.d which are version controlled:

   ~/.emacs.d$ git ls-files
   _abbrev_defs
   _diary
   _gnus
   init.el

Now I start emacs:

   emacs -Q -n 

and evaluate

   (getenv "GIT_DIR")

this shows 

   "/home/grfz/.fgits/emacs.git"

in the echo area, while 

   (getenv "GIT_WORK_TREE")

gives

   "/home/grfz/.fgits/emacs.git/../../"

That's o.k.  Now I ^X f visit ~/.emacs.d/init.el but no
indication that init.el is version controlled shows up in the
mode line: 

   -UUU:----F1  init.el        Top L1     (Emacs-Lisp)----------------------------------------------------------

Now I type ^X v d (vc-dir), emacs asks 

   VC status for directory: ~/.emacs.d/

when I confirm this, I get the message

   No VC backend is responsible for /home/grfz/.emacs.d/

in the echo area.



vc does not support the specific git feature of detatched repositories.  
Therefore I file this bugreport / wishlist bug:  IMHO vc should
support this feature.  In order to do so vc should honour the
environment variables GIT_DIR and GIT_WORK_TREE respectively and
utilize the git ls-files directory.  git gives
precedence to these environment variables: even if there is a
.git directory with reository it will be ignored if the
environment variables indicate other locations for repository and
working directory.  I think vc should behave in the same way.




Thanx for your attention, 
Gregor

[1] 
These "fake bare repos" are created like this:
   export GIT_DIR=~/.fgits/emacs.git 
   git init --bare 
   git config core.bare false 
   git config core.worktree ../../ 
   git config status.showUntrackedFiles no
see http://lists.madduck.net/pipermail/vcs-home/2008-August/000175.html
for an explanation of this way of keeping dotfiles under version
control. 



If Emacs crashed, and you have the Emacs process in the gdb debugger,
please include the output from the following gdb commands:
    `bt full' and `xbacktrace'.
For information about debugging Emacs, please read the file
/usr/share/emacs/23.1.91/etc/DEBUG.


In GNU Emacs 23.1.91.1 (i486-pc-linux-gnu, GTK+ Version 2.18.5)
 of 2010-01-06 on elegiac, modified by Debian
 (emacs-snapshot package, version 1:20100106-1)
Windowing system distributor `The X.Org Foundation', version 11.0.10605000
configured using `configure  '--build' 'i486-linux-gnu' '--host' 'i486-linux-gnu' '--prefix=/usr' '--sharedstatedir=/var/lib' '--libexecdir=/usr/lib' '--localstatedir=/var' '--infodir=/usr/share/info' '--mandir=/usr/share/man' '--with-pop=yes' '--enable-locallisppath=/etc/emacs-snapshot:/etc/emacs:/usr/local/share/emacs/23.1.91/site-lisp:/usr/local/share/emacs/site-lisp:/usr/share/emacs/23.1.91/site-lisp:/usr/share/emacs/site-lisp' '--with-x=yes' '--with-x-toolkit=gtk' 'build_alias=i486-linux-gnu' 'host_alias=i486-linux-gnu' 'CFLAGS=-DDEBIAN -DSITELOAD_PURESIZE_EXTRA=5000 -g -O2' 'LDFLAGS=-g -Wl,--as-needed' 'CPPFLAGS=''

Important settings:
  value of $LC_ALL: nil
  value of $LC_COLLATE: de_DE.utf8
  value of $LC_CTYPE: de_DE.utf8
  value of $LC_MESSAGES: POSIX
  value of $LC_MONETARY: de_DE.utf8
  value of $LC_NUMERIC: de_DE.utf8
  value of $LC_TIME: de_DE.utf8
  value of $LANG: de_DE.utf8
  value of $XMODIFIERS: nil
  locale-coding-system: utf-8-unix
  default enable-multibyte-characters: t

Major mode: Lisp Interaction

Minor modes in effect:
  tooltip-mode: t
  mouse-wheel-mode: t
  tool-bar-mode: t
  menu-bar-mode: t
  file-name-shadow-mode: t
  global-font-lock-mode: t
  font-lock-mode: t
  blink-cursor-mode: t
  global-auto-composition-mode: t
  auto-composition-mode: t
  auto-encryption-mode: t
  auto-compression-mode: t
  line-number-mode: t
  transient-mark-mode: t

Recent input:
( g e t e n v SPC " G I T _ D I R " ) C-x C-e <return> 
M-x e m a <tab> b <backspace> <backspace> <backspace> 
<backspace> <backspace> <backspace> <backspace> r e 
p o <tab> r <tab> <return>

Recent messages:
For information about GNU Emacs and the GNU system, type C-h C-a.
"/home/grfz/.fgits/emacs.git"
Making completion list...

Load-path shadows:
/usr/share/emacs/23.1.91/site-lisp/debian-startup hides /usr/share/emacs/site-lisp/debian-startup
/usr/share/emacs/23.1.91/site-lisp/emms/tq hides /usr/share/emacs/23.1.91/lisp/emacs-lisp/tq

Features:
(shadow sort mail-extr message sendmail regexp-opt ecomplete rfc822 mml
mml-sec password-cache mm-decode mm-bodies mm-encode mailcap mail-parse
rfc2231 rfc2047 rfc2045 qp ietf-drums mailabbrev nnheader gnus-util
netrc time-date mm-util mail-prsvr gmm-utils wid-edit mailheader canlock
sha1 hex-util hashcash mail-utils emacsbug help-mode easymenu view
tooltip ediff-hook vc-hooks lisp-float-type mwheel x-win x-dnd
font-setting tool-bar dnd fontset image fringe lisp-mode register page
menu-bar rfn-eshadow timer select scroll-bar mldrag mouse jit-lock
font-lock syntax facemenu font-core frame cham georgian utf-8-lang
misc-lang vietnamese tibetan thai tai-viet lao korean japanese hebrew
greek romanian slovak czech european ethiopic indian cyrillic chinese
case-table epa-hook jka-cmpr-hook help simple abbrev loaddefs button
minibuffer faces cus-face files text-properties overlay md5 base64
format env code-pages mule custom widget hashtable-print-readable
backquote make-network-process dbusbind font-render-setting gtk
x-toolkit x multi-tty emacs)

bug#5344: 23.1.91; bug/wish: vc does not honour GIT_DIR / GIT_WORK_TREE environment variables

[Dan Nicolaescu]

Gregor Zattler <grfz@gmx.de> writes:

  > Dear emacs developers,
  > 
  > I use bare git repositories for version contol of some dotfiles.[1] This
  > means that the repository ist *not* in a .git directory which is part of
  > the working directorys hirarchy.  Instead the environment variable
  > GIT_DIR indicates the location of the repository and the environment
  > variable GIT_WORK_TREE indicates the working directory.  But in emacs/vc
  > these dotfiles do not show up as version controlled, even when the emacs
  > session inherited the correct GIT_* environment variables:
  > 
  >    ~$ export GIT_DIR=~/.fgits/emacs.git
  >    ~$ export GIT_WORK_TREE="$GIT_DIR/$(git config --get core.worktree)"
  >    ~$ printenv|grep GIT
  >    GIT_DIR=/home/grfz/.fgits/emacs.git
  >    GIT_WORK_TREE=/home/grfz/.fgits/emacs.git/../../

If you want to add support for this, it's quite likely that the only
thing that needs to be changed is the vc-git-root in
emacs/lisp/vc-git.el.

bug#5344: 23.1.91; bug/wish: vc does not honour GIT_DIR / GIT_WORK_TREE environment variables

[Gregor Zattler]

Hi Dan,
* Dan Nicolaescu <dann@ics.uci.edu> [09. Jan. 2010]:
> Gregor Zattler <grfz@gmx.de> writes:
>   > I use bare git repositories for version contol of some dotfiles.[1] This
>   > means that the repository ist *not* in a .git directory which is part of
>   > the working directorys hirarchy.  Instead the environment variable
>   > GIT_DIR indicates the location of the repository and the environment
>   > variable GIT_WORK_TREE indicates the working directory.  But in emacs/vc
>   > these dotfiles do not show up as version controlled, even when the emacs
>   > session inherited the correct GIT_* environment variables:
>   > 
>   >    ~$ export GIT_DIR=~/.fgits/emacs.git
>   >    ~$ export GIT_WORK_TREE="$GIT_DIR/$(git config --get core.worktree)"
>   >    ~$ printenv|grep GIT
>   >    GIT_DIR=/home/grfz/.fgits/emacs.git
>   >    GIT_WORK_TREE=/home/grfz/.fgits/emacs.git/../../
> 
> If you want to add support for this, it's quite likely that the only
> thing that needs to be changed is the vc-git-root in
> emacs/lisp/vc-git.el.

Sorry I'm not capable to do this.  That's the reason I called it
a wish list bug.

Because of your suggestion I have fiddled around a bit and found
a workaround which somehow supports your suggestion::

I initilalised an empty repository ~/.git.  Now vc "considers"
my whole home directory as potentially version controlled and
interacts with git.  Git in turn honours the environment
variables and voila:  many of the vc-commands are working now.
Since I do not want to use this ~/.git I did a 
   chmod -R a-w ~/.git
in order to prevent accidentially using this repository in stead
of one of the detached ones.


Thanks for the hint.
Gregor

bug#5344: 23.1.91; bug/wish: vc does not honour GIT_DIR / GIT_WORK_TREE environment variables

[Gregor Zattler]

tags patch
thanks

Hi Dan,
* Dan Nicolaescu <dann@ics.uci.edu> [09. Jan. 2010]:
> If you want to add support for this, it's quite likely that the only
> thing that needs to be changed is the vc-git-root in
> emacs/lisp/vc-git.el.

O.K. thanks to your pointer this was really easy.  I don't know
if there are negative side effects or if it's a complete solution
to the problem but it works for me.  The patch does not normalize
the resulting path, though.  Don't know if this is a problem.
For instance (vc-git-root "~/.emacs.d/init.el") gives me:
"/home/grfz/.fgits/emacs.git/../../"

I don't know if other version controll systems have similar means
of detaching repository and working directory.  Then vc-find-root
would perhaps be a better place to patch.  But thats beyond me.

Thank you *very* much.

Now I have to learn how to use emacsclients environment for this
purpose instead of the daemon ones.

Gregor


--- vc-git.el	2010-01-10 22:51:23.000000000 +0100
+++ my-vc-git.el	2010-01-10 23:24:55.000000000 +0100
@@ -777,7 +777,9 @@
 (defun vc-git-extra-status-menu () vc-git-extra-menu-map)
 
 (defun vc-git-root (file)
-  (vc-find-root file ".git"))
+(if (getenv "GIT_DIR") 
+  (getenv "GIT_WORK_TREE")
+ (vc-find-root file ".git")))
 
 (defun vc-git-toggle-signoff ()
   (interactive)

bug#5344: 23.1.91; bug/wish: vc does not honour GIT_DIR / GIT_WORK_TREE environment variables

[Lars Ingebrigtsen]

Gregor Zattler <grfz@gmx.de> writes:

>  (defun vc-git-root (file)
> -  (vc-find-root file ".git"))
> +(if (getenv "GIT_DIR") 
> +  (getenv "GIT_WORK_TREE")
> + (vc-find-root file ".git")))

As far as I can tell by skimming vc-git.el, functionality like this has
not been added during the intervening years.  The use case it:

> I use bare git repositories for version contol of some dotfiles.[1] This
> means that the repository ist *not* in a .git directory which is part of
> the working directorys hirarchy.  Instead the environment variable
> GIT_DIR indicates the location of the repository and the environment
> variable GIT_WORK_TREE indicates the working directory.

We wouldn't want to add this in the form suggested above, but it does
sound like a useful feature, if I understand it correctly.  But I don't
quite see how you'd tie a specific location to a specific GIT_DIR value,
so I don't see how this would work in general.  Perhaps fall back on
GIT_DIR/GIR_WORK_TREE if vc-git-root returns nil would be reasonable?

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

bug#5344: 23.1.91; bug/wish: vc does not honour GIT_DIR / GIT_WORK_TREE environment variables

[Lars Ingebrigtsen]

(Please keep the debbugs address in the Cc header -- otherwise the mail
doesn't reach the bug tracker.)

Gregor Zattler <grfz@gmx.de> writes:

> Actually git does it the other way around: It uses the values of
> the environment variables even if there is a .git directory
> further up in the file system hierarchy.  So it's not a fall
> back but it overrides the default.

The vc functions in Emacs sets GIT_DIR to "" before calling git, so in
vc mode it would be a fallback.

> When I wrote this bug report and later the tiny patch, what I
> wanted was to edit dotfiles with emacsclient from the terminal
> command line in terminal frames.  But in several terminals there
> are several shells with possibly different GIT_DIR/GIR_WORK_TREE
> environment variables.
>
> But working with emacsclient there is only one emacs server and
> therefore only one pair of GIT_DIR/GIR_WORK_TREE variables.
>
> To work with git from the command line with emacsclient the
> environment variables would have to be frame local.
>
> This is where I stuck.
>
> Therefore nowadays I'm back to a single ~/.git directory, not
> using the environment variables any more.  And I'm working with
> magit nowadays.  Magit also does not support the
> GIT_DIR/GIR_WORK_TREE environment variables.
>
> There are interesting discussions on this topic here:
> https://github.com/magit/magit/issues/2939#issuecomment-271186636
> and here: https://github.com/magit/magit/issues/460
>
> These are attempts to solve the pu:
> https://gitlab.com/stepnem/vcsh-el
> https://github.com/vanicat/magit-vcsh

It seems like providing a simple alist of directories/git repos would do
the trick in vc-dir, wouldn't it?

bug#5344: 23.1.91; bug/wish: vc does not honour GIT_DIR / GIT_WORK_TREE environment variables

[Gregor Zattler]

Hi Lars,

sorry for the delay.
* Lars Ingebrigtsen <larsi@gnus.org> [2019-11-24; 22:46]:
> Gregor Zattler <grfz@gmx.de> writes:
>> Actually git does it the other way around: It uses the values of
>> the environment variables even if there is a .git directory
>> further up in the file system hierarchy.  So it's not a fall
>> back but it overrides the default.
>
> The vc functions in Emacs sets GIT_DIR to "" before calling git, so in
> vc mode it would be a fallback.

I don't have much clue but perhaps this is the wrong thing to do?


>> But working with emacsclient there is only one emacs server and
>> therefore only one pair of GIT_DIR/GIR_WORK_TREE variables.
>>
>> To work with git from the command line with emacsclient the
>> environment variables would have to be frame local.
>>
>> This is where I stuck.
>>
>> Therefore nowadays I'm back to a single ~/.git directory, not
>> using the environment variables any more.  And I'm working with
>> magit nowadays.  Magit also does not support the
>> GIT_DIR/GIR_WORK_TREE environment variables.
>>
>> There are interesting discussions on this topic here:
>> https://github.com/magit/magit/issues/2939#issuecomment-271186636
>> and here: https://github.com/magit/magit/issues/460
>>
>> These are attempts to solve the pu:
>> https://gitlab.com/stepnem/vcsh-el
>> https://github.com/vanicat/magit-vcsh
>
> It seems like providing a simple alist of directories/git repos would do
> the trick in vc-dir, wouldn't it?

Actually I don't know.  Sorry, I'm no help here.


Ciao,
--
Gregor

bug#5344: 23.1.91; bug/wish: vc does not honour GIT_DIR / GIT_WORK_TREE environment variables

[Robert Pluim]

>>>>> On Sun, 01 Dec 2019 11:53:01 +0100, Gregor Zattler <grfz@gmx.de> said:

    Gregor> Hi Lars,
    Gregor> sorry for the delay.
    Gregor> * Lars Ingebrigtsen <larsi@gnus.org> [2019-11-24; 22:46]:
    >> Gregor Zattler <grfz@gmx.de> writes:
    >>> Actually git does it the other way around: It uses the values of
    >>> the environment variables even if there is a .git directory
    >>> further up in the file system hierarchy.  So it's not a fall
    >>> back but it overrides the default.
    >> 
    >> The vc functions in Emacs sets GIT_DIR to "" before calling git, so in
    >> vc mode it would be a fallback.

    Gregor> I don't have much clue but perhaps this is the wrong thing to do?

Itʼs the right thing to do in the context of vc, where it only
supports the directory-based model of repository. Setting GIT_DIR to
"" avoids having the environment of the shell where you started emacs
messing up VC.

    >> It seems like providing a simple alist of directories/git repos would do
    >> the trick in vc-dir, wouldn't it?

No. Define a variable that will be used by vc to override what it
thinks the current repository is, and then use .dir-locals.el to set
it per-directory. Patches welcome :-)

Robert