Vcsh isn't compatible with Magit

[GregorZattler]

Magit 20170106.1903, Git 2.11.0, Emacs 25.1.91.1, gnu/linux

I use vcsh to manage my dotfiles (see post scriptum for details). This approach uses various bare repos with the same GIT_WORKTREE (which is usally $HOME). Which means that at the moment in my emacs server instance I see (via eshell):

~/.emacs.d $ ~/.emacs.d $ printenv | grep GIT 
GIT_DIR=/home/grfz/.config/vcsh/repo.d/emacs.git
~/.emacs.d $ git config --get-all core.worktree
/home/grfz

because I edited my emacs dotfiles. Now I want to use another repo:

When I issue magit-list-repositories I see my configured repos which are not vcsh bare repos but normal repos e.g. under ~/src, e.g. ~/src/org-mode. Hitting RET on this line results in a magit-status for the vcsh emacs bare repo instead of magit-status
for the org-mode repo (because ~/src/org-mode is below ~/).

In eshell:

~/src/org-mode $ git config --get-all core.worktree
/home/grfz

When I try to force magit status on the org-mode directory in eshell:

~/src/org-mode $ magit-status .

magit asks me:
/home/grfz/ is a repository. Create another in /home/grfz/src/org-mode/? (y or n)

I would expect that magit-repolist-status would force magit to "change to" the selected repo no matter what.

A command magit-forget-current-repo would also do.

Thanks for your attention, Gregor

P.S.: Details regarding working with files under vcsh in emacs:

One visits files via a tramp-method "vcsh":

emacsclient -a '' /vcsh:<name-of-vcsh-repo>:<filename-tracked-by-vcsh>

In my case it was: /vcsh:emacs:~/.emacs.d/init.el

This is how to configure the tramp method:

(add-to-list 'tramp-methods '("vcsh"
                              (tramp-login-program "vcsh")
                              (tramp-login-args
                               (("enter")
                                ("%h")))
                              (tramp-remote-shell "/bin/sh")
                              (tramp-remote-shell-args
                               ("-c"))))

[GregorZattler]

Thanks. How about:

A command magit-forget-current-repo would also do.
and marking it as a feature request (I don't know how to do this)?

[tarsius]

Vcsh has been discussed before in #460. That's a very old issue so what is being said there with a grain of salt. (I am pretty sure this has come up a few more times, but that's all I can find right now.)

Git provides two mechanism for separating the git directory from the working tree: (1) environment variables and (2) ".git is a regular file that points at the real .git/".

(1) is very suitable for scripting but it is not suitable for interactive tools. Unfortunately that's what vcsh does. This has immediate negative consequences for vcsh itself. For example you cannot vcsh select emacs and then operate on the emacs repository in every shell whose working directory is ~/ (or a subdirectory). Instead you have to use vcsh enter emacs, which starts a new subshell in which the variables have been set appropriately.

Emacs is "like many shells" in a sense. Like each shell instance has its own working directory, which can be changed independently; each Emacs buffer has its own default-directory, which also can be changed independently, without affecting that of other buffers.

However unlike multiple shells, each of which has its own environments, all Emacs buffer share the same environment. If you change an environment variable inside Emacs using e.g. setenv, then that affects all buffers. So you can change the default-directory as much as you want (e.g. by switching to another buffer were that has another value), but $GIT_DIR will always win.

The use of Tramp's vcsh method somewhat mitigates this. If you use Tramp to run some process on another machine using e.g. the ssh method, then you obviously want to do so using the environment suitable for that machine not the local one. So Tramp does maintain separate environments for the buffers it opens, and the vcsh method makes use of that feature.

---

Your steps above are quite complicated (i.e. specific to your particular workflow) and most of it is irrelevant I believed. Let's simplify as follows.

1. C-x f "/vcsh:emacs:~/.emacs.d/init.el)
2. M-x magit-list-repositories

The default-directory of the resulting buffer now likely is /vcsh:emacs:~/.emacs.d. So the environment is under the control of Tramp. If you now visit another repository, then the /vcsh:emacs prefix remains and so the Tramp environment for that "remote" connection stays in effect.

---

I am not going to add support for vcsh to Magit. Such support would amount to many kludges that work around vcsh's mistake of using environment variables. I have not changed my opinion about that since it last came up, vcsh's basic design decision is wrong. It works when using vcsh by itself, i.e. when running git commands in a shell, but when combining with vcsh with other tools, things break, and vcsh is the one who is at fault.

By the way I have implemented a proof-of-concept alternative to vcsh, which demonstrates that the other approach works very well. It only implements two commands link (make some repository active) and unlink (make no repository active). But that's pretty much all that is needed (you would also want create to create a new repository). All other vcsh commands are either niceties (like list) or only required due to the initial design mistake.

Hell, I am going to might invest an hour or so to make my version feature complete, meanwhile you can find the incomplete implementation at the end of #460.

[GregorZattler]

The default-directory of the resulting buffer now likely is /vcsh:emacs:~/.emacs.d.

Thanks, this was it. I changed default-directory via cd then visiting repos in magit-list-repositories worked.

[stepnem]

I have updated, corrected, modified and extended the #460 snippet and
turned it into a library: https://gitlab.com/stepnem/vcsh-el

[tarsius]

Checkdoc: can you guess what ORIG and ARGS mean?

😀

If you open a Melpa pull-request for this, then summon me to speed up the process.

[tarsius]

You should add ;; Package-Requires: ((emacs "24.4")). package-lint also mentions that you might want to add Package-Version or Version. I recommend you ignore that. I would also recommend removing the vcsh-version variable and relying exclusively on Git tags to provide version information.

[stepnem]

Thanks, I had no real intention of package submission, somehow I still live in the pre-package world; although I do rely on epkg a lot, which relies on MELPA, so maybe I should just bite the bullet. I think it's useful to keep at least one of version header/variable for VCS-less scenarios.

((emacs "24.4"))

This one's interesting, though. Is 24.4 just slapped there because that's the first version with decent-enough package support built-in, or does package-lint actually compute something? In any case, I'd expect magit should go there, not emacs. This is getting rather off-topic, maybe better continue by e-mail?

[tarsius]

Epkg does not rely on Melpa. I use data from Melpa in order to add packages to the Emacsmirror database used by Epkg, but from a user perspective that isn't a dependency. Instead of going the package.el route, you might want to give Borg a try.

package-lint actually compute something?

It contains data that claims that lexical-binding, advice-add and advice-remove made their first appearance in version 24.4 of Emacs. It doesn't have anything to do with when package.el was added to Emacs (it was 24.1 I believe).

In any case, I'd expect magit should go there, not emacs.

Right. 😁 (You don't need to also specify the minimal Emacs version because depending on Magit already takes care of that.) I recommend you depend on the latest Magit version (2.90.1) even though this would likely work with older versions too.

This is getting rather off-topic, maybe better continue by e-mail?

Ah well. Too late for that now.

[npostavs]

It contains data that claims that lexical-binding, advice-add and advice-remove made their first appearance in version 24.4 of Emacs.

lexical-binding was introduced in 24.1. It's correct about the advice-* functions though.

[tarsius]

Actually it is correct about lexical-binding too. I did not look closely enough and though it suggested 24.4 for the sake of all of these symbols, but actually it says: 1:38: warning: You should depend on (emacs "24") if you need lexical-binding..

[stepnem]

On Thu, 08 Aug 2019 03:30:56 -0700 Jonas Bernoulli wrote: Epkg does not rely on Melpa. I use data from Melpa in order to add packages to the Emacsmirror database used by Epkg, but from a user perspective that isn't a dependency.

I know it could work without MELPA (and I've been using borg almost since the beginning), "rely" was simply supposed to mean that it is the main package/data source, albeit indirectly. Thanks.

[tarsius]

(and I've been using borg almost since the beginning)

That's probably why your avatar image looked familiar.
Good for you! Of course I suggest you stick with that then. ;-)

Anyway... once you have added the Package-Requires header I can add the recipe myself.

[stepnem]

Anyway... once you have added the Package-Requires header I can add the recipe myself.

No nepotism! :-D I'll do it. I'm in no hurry and kinda curious about the procedure.