-
-
Notifications
You must be signed in to change notification settings - Fork 812
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Vcsh isn't compatible with Magit #2939
Comments
Thanks. How about:
|
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) " (1) is very suitable for scripting but it is not suitable for interactive tools. Unfortunately that's what 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 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. The use of Tramp's 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.
The I am not going to add support for By the way I have implemented a proof-of-concept alternative to Hell, I |
Thanks, this was it. I changed default-directory via |
I have updated, corrected, modified and extended the #460 snippet and |
😀 If you open a Melpa pull-request for this, then summon me to speed up the process. |
You should add |
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?
|
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
It contains data that claims that
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.
Ah well. Too late for that now. |
|
Actually it is correct about |
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.
|
That's probably why your avatar image looked familiar. Anyway... once you have added the Package-Requires header I can add the recipe myself. |
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.
|
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):
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:
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:
The text was updated successfully, but these errors were encountered: