magit won’t work over TRAMP

OpenSubmitted by Ricardo Wurmus.
Details
5 participants
  • Alex Kost
  • Maxim Cournoyer
  • Maxime Devos
  • Mark H Weaver
  • Ricardo Wurmus
Owner
unassigned
Severity
normal
R
R
Ricardo Wurmus wrote on 12 Feb 2018 13:53
(address . bug-guix@gnu.org)
87lgfyl67x.fsf@elephly.net
The default value for “magit-git-executable” (when magit is installed
via Guix) appears to be a store path, such as
“/gnu/store/l7g5r1c2i0bf3cd71g53ajy8khdcyidz-git-2.16.1/bin/git”. This
means that when magit is used over TRAMP it will try to find the exact
same git executable on the remote.

Instead, magit should only look for “git” on the remote, not for the
exact store location of a particular git executable.

I could only use magit over TRAMP after setting “magit-git-executable”
to “git”.

--
Ricardo

GPG: BCA6 89B6 3655 3801 C3C6 2150 197A 5888 235F ACAC
A
A
Alex Kost wrote on 12 Feb 2018 18:33
(name . Ricardo Wurmus)(address . rekado@elephly.net)(address . 30434@debbugs.gnu.org)
87mv0e2jvm.fsf@gmail.com
Ricardo Wurmus (2018-02-12 13:53 +0100) wrote:

Toggle quote (12 lines)
> The default value for “magit-git-executable” (when magit is installed
> via Guix) appears to be a store path, such as
> “/gnu/store/l7g5r1c2i0bf3cd71g53ajy8khdcyidz-git-2.16.1/bin/git”. This
> means that when magit is used over TRAMP it will try to find the exact
> same git executable on the remote.
>
> Instead, magit should only look for “git” on the remote, not for the
> exact store location of a particular git executable.
>
> I could only use magit over TRAMP after setting “magit-git-executable”
> to “git”.

If people will agree that changing 'magit-git-executable' is not needed,
then I think 'git' can be removed from the inputs as it is used just for
that variable.

P.S. I also use just "git" for 'magit-git-executable'.

--
Alex
M
M
Mark H Weaver wrote on 12 Feb 2018 20:51
(name . Alex Kost)(address . alezost@gmail.com)
87bmguq94j.fsf@netris.org
Alex Kost <alezost@gmail.com> writes:

Toggle quote (20 lines)
> Ricardo Wurmus (2018-02-12 13:53 +0100) wrote:
>
>> The default value for “magit-git-executable” (when magit is installed
>> via Guix) appears to be a store path, such as
>> “/gnu/store/l7g5r1c2i0bf3cd71g53ajy8khdcyidz-git-2.16.1/bin/git”. This
>> means that when magit is used over TRAMP it will try to find the exact
>> same git executable on the remote.
>>
>> Instead, magit should only look for “git” on the remote, not for the
>> exact store location of a particular git executable.
>>
>> I could only use magit over TRAMP after setting “magit-git-executable”
>> to “git”.
>
> If people will agree that changing 'magit-git-executable' is not needed,
> then I think 'git' can be removed from the inputs as it is used just for
> that variable.
>
> P.S. I also use just "git" for 'magit-git-executable'.

That's fine with me. IIRC, I was the one who arranged to set
'magit-git-executable' to an absolute path in the store, but in
retrospect I'm not sure it makes sense in this case, especially if it
breaks TRAMP.

Regards,
Mark
R
R
Ricardo Wurmus wrote on 12 Feb 2018 20:11
(name . Alex Kost)(address . alezost@gmail.com)(address . 30434@debbugs.gnu.org)
876072koq0.fsf@elephly.net
Alex Kost <alezost@gmail.com> writes:

Toggle quote (20 lines)
> Ricardo Wurmus (2018-02-12 13:53 +0100) wrote:
>
>> The default value for “magit-git-executable” (when magit is installed
>> via Guix) appears to be a store path, such as
>> “/gnu/store/l7g5r1c2i0bf3cd71g53ajy8khdcyidz-git-2.16.1/bin/git”. This
>> means that when magit is used over TRAMP it will try to find the exact
>> same git executable on the remote.
>>
>> Instead, magit should only look for “git” on the remote, not for the
>> exact store location of a particular git executable.
>>
>> I could only use magit over TRAMP after setting “magit-git-executable”
>> to “git”.
>
> If people will agree that changing 'magit-git-executable' is not needed,
> then I think 'git' can be removed from the inputs as it is used just for
> that variable.
>
> P.S. I also use just "git" for 'magit-git-executable'.

It took me way too long to figure out that this was the cause. I played
with TRAMP settings before that and only noticed that something was off
when I looked at the verbose TRAMP debug logs.

I think it makes sense *not* to hardcode the path to the git executable
here.

--
Ricardo

GPG: BCA6 89B6 3655 3801 C3C6 2150 197A 5888 235F ACAC
M
M
Mark H Weaver wrote on 14 Feb 2018 09:51
(name . Ricardo Wurmus)(address . rekado@elephly.net)
87wozgosxx.fsf@netris.org
Ricardo Wurmus <rekado@elephly.net> writes:
Toggle quote (3 lines)
> I think it makes sense *not* to hardcode the path to the git executable
> here.

Agreed. Done, in commit 5fe9ba59ba1cea12a70d011aacbace52e3bfda18 on
master and commit 317e8e9404058af35d9843e076934560f95d895a on
core-updates. I'm closing this bug now.

Thanks,
Mark
Closed
A
A
Alex Kost wrote on 14 Feb 2018 18:00
(address . 30434@debbugs.gnu.org)
871shny0a1.fsf@gmail.com
Mark H Weaver (2018-02-14 03:51 -0500) wrote:

Toggle quote (8 lines)
> Ricardo Wurmus <rekado@elephly.net> writes:
>> I think it makes sense *not* to hardcode the path to the git executable
>> here.
>
> Agreed. Done, in commit 5fe9ba59ba1cea12a70d011aacbace52e3bfda18 on
> master and commit 317e8e9404058af35d9843e076934560f95d895a on
> core-updates. I'm closing this bug now.

You didn't remove "git" from the inputs. I think it is not needed now.

--
Alex
M
M
Mark H Weaver wrote on 14 Feb 2018 19:17
(name . Alex Kost)(address . alezost@gmail.com)
877erfph9m.fsf@netris.org
Hi Alex,

Alex Kost <alezost@gmail.com> writes:

Toggle quote (12 lines)
> Mark H Weaver (2018-02-14 03:51 -0500) wrote:
>
>> Ricardo Wurmus <rekado@elephly.net> writes:
>>> I think it makes sense *not* to hardcode the path to the git executable
>>> here.
>>
>> Agreed. Done, in commit 5fe9ba59ba1cea12a70d011aacbace52e3bfda18 on
>> master and commit 317e8e9404058af35d9843e076934560f95d895a on
>> core-updates. I'm closing this bug now.
>
> You didn't remove "git" from the inputs. I think it is not needed now.

I removed it on my first attempt, but the build failed. See below.

Mark

Toggle snippet (42 lines)
starting phase `build'
Cannot open load file: No such file or directory, /tmp/guix-build-magit-2.11.0.drv-0/magit-2.11.0/magit-version.el
make[1]: Entering directory '/tmp/guix-build-magit-2.11.0.drv-0/magit-2.11.0/Documentation'
make[1]: Entering directory '/tmp/guix-build-magit-2.11.0.drv-0/magit-2.11.0/lisp'
Cannot open load file: No such file or directory, /tmp/guix-build-magit-2.11.0.drv-0/magit-2.11.0/Documentation/magit-version.el
Generating magit.info
Compiling git-commit.el
Compiling magit-popup.el
Compiling magit-utils.el
Generating magit-autoloads.el
Generating magit-version.el
Compiling magit-section.el
Compiling magit-git.el
Compiling magit-mode.el
Compiling magit-margin.el
Compiling magit-process.el
Generating magit-popup.info
Compiling magit-autorevert.el
Compiling magit-core.el
Compiling magit-diff.el
Generating dir
make[1]: Leaving directory '/tmp/guix-build-magit-2.11.0.drv-0/magit-2.11.0/Documentation'
Compiling magit-repos.el
Compiling magit-log.el
Compiling magit-wip.el
Compiling magit-apply.el
Compiling magit.el
Compiling magit-refs.el
Compiling magit-status.el

In toplevel form:
magit-status.el:30:1:Error: Searching for program: No such file or directory, git
make[1]: *** [Makefile:61: magit-status.elc] Error 1
make[1]: *** Waiting for unfinished jobs....

In toplevel form:
magit-refs.el:30:1:Error: Searching for program: No such file or directory, git
make[1]: *** [Makefile:61: magit-refs.elc] Error 1
make[1]: Leaving directory '/tmp/guix-build-magit-2.11.0.drv-0/magit-2.11.0/lisp'
make: *** [Makefile:75: lisp] Error 2
phase `build' failed after 7.5 seconds
A
A
Alex Kost wrote on 15 Feb 2018 20:38
(name . Mark H Weaver)(address . mhw@netris.org)
87po56avqn.fsf@gmail.com
Mark H Weaver (2018-02-14 13:17 -0500) wrote:

Toggle quote (18 lines)
> Hi Alex,
>
> Alex Kost <alezost@gmail.com> writes:
>
>> Mark H Weaver (2018-02-14 03:51 -0500) wrote:
>>
>>> Ricardo Wurmus <rekado@elephly.net> writes:
>>>> I think it makes sense *not* to hardcode the path to the git executable
>>>> here.
>>>
>>> Agreed. Done, in commit 5fe9ba59ba1cea12a70d011aacbace52e3bfda18 on
>>> master and commit 317e8e9404058af35d9843e076934560f95d895a on
>>> core-updates. I'm closing this bug now.
>>
>> You didn't remove "git" from the inputs. I think it is not needed now.
>
> I removed it on my first attempt, but the build failed. See below.

Oh, right, sorry. I use my own package for magit and it dosn't require
git input, so I thought that the original guix package also doesn't need
it. Sorry for the confusion :-)

--
Alex
M
M
Mark H Weaver wrote on 16 Feb 2018 10:09
(name . Alex Kost)(address . alezost@gmail.com)
873721mhbh.fsf@netris.org
Alex Kost <alezost@gmail.com> writes:

Toggle quote (12 lines)
> Mark H Weaver (2018-02-14 13:17 -0500) wrote:
>
>> Alex Kost <alezost@gmail.com> writes:
>>
>>> You didn't remove "git" from the inputs. I think it is not needed now.
>>
>> I removed it on my first attempt, but the build failed. See below.
>
> Oh, right, sorry. I use my own package for magit and it dosn't require
> git input, so I thought that the original guix package also doesn't need
> it. Sorry for the confusion :-)

How does your own magit package avoid requiring git as an input? I'd be
curious to see the diff between your package definition and ours.

Mark
A
A
Alex Kost wrote on 16 Feb 2018 17:56
(name . Mark H Weaver)(address . mhw@netris.org)(address . 30434@debbugs.gnu.org)
874lmg6fgb.fsf@gmail.com
Mark H Weaver (2018-02-16 04:09 -0500) wrote:

Toggle quote (17 lines)
> Alex Kost <alezost@gmail.com> writes:
>
>> Mark H Weaver (2018-02-14 13:17 -0500) wrote:
>>
>>> Alex Kost <alezost@gmail.com> writes:
>>>
>>>> You didn't remove "git" from the inputs. I think it is not needed now.
>>>
>>> I removed it on my first attempt, but the build failed. See below.
>>
>> Oh, right, sorry. I use my own package for magit and it dosn't require
>> git input, so I thought that the original guix package also doesn't need
>> it. Sorry for the confusion :-)
>
> How does your own magit package avoid requiring git as an input? I'd be
> curious to see the diff between your package definition and ours.

My version of magit is attached. Actually this problem (requiring git
during compilation) was introduced occasionally in Magit 2.11.0 and was
fixed soon after that, so "git" input will not be needed in the next
release.

If you want more details, tarsius (the maintainer of Magit) added some
code to bring attention for his fundraising campaign:


Then he made a release (2.11.0), but that commit introduced the
compilation fail if git wasn't available at compile-time. This was
fixed right after the release (at the same day):


Finally the campaign code was removed 2 weeks later:

(define-public my-emacs-magit (package (inherit magit) (name "my-emacs-magit") (arguments (substitute-keyword-arguments (package-arguments magit) ((#:phases phases) `(modify-phases ,phases (replace 'patch-exec-paths (lambda _ (with-directory-excursion "lisp" ;; "magit.el" calls 'magit-startup-asserts' and ;; 'magit-version' functions in the top level. I don't ;; need it at all. (emacs-batch-edit-file "magit.el" `(progn (goto-char (point-min)) (re-search-forward "(if after-init-time") (up-list -1) (kill-sexp) (basic-save-buffer))) (emacs-substitute-variables "magit-git.el" ("magit-git-executable" "git")) ;; XXX Campaign header was introduced in Magit 2.11.0 ;; and will be removed in the next release: ;; ;; https://github.com/magit/magit/commit/bf71241122e1a0bf707913c87493214ceb12f588 ;; https://github.com/magit/magit/commit/4a9d9e59806735100b5d20a8be32defefb659a33 ;; ;; Change the value of 'magit-hide-campaign-header' ;; variable since it calls 'git' during initializing. (emacs-substitute-variables "magit-status.el" ("magit-hide-campaign-header" 't)) #t))))))) (inputs '()) (synopsis (string-append (package-synopsis magit) " (without git dependency)"))))
M
M
Mark H Weaver wrote on 16 Feb 2018 20:00
(name . Alex Kost)(address . alezost@gmail.com)(address . 30434@debbugs.gnu.org)
87eflklpy5.fsf@netris.org
Hi Alex,

Alex Kost <alezost@gmail.com> writes:

Toggle quote (15 lines)
> Mark H Weaver (2018-02-16 04:09 -0500) wrote:
>
>> How does your own magit package avoid requiring git as an input? I'd be
>> curious to see the diff between your package definition and ours.
>
> My version of magit is attached. Actually this problem (requiring git
> during compilation) was introduced occasionally in Magit 2.11.0 and was
> fixed soon after that, so "git" input will not be needed in the next
> release.
>
> If you want more details, tarsius (the maintainer of Magit) added some
> code to bring attention for his fundraising campaign:
>
> https://github.com/magit/magit/commit/bf71241122e1a0bf707913c87493214ceb12f588

Thanks for interesting details, and for your modified 'magit' package
recipe. Having looked it over, I'm inclined to leave our 'magit'
package as it is now. It's a very quick build, and also a leaf package
(except for 'magit-svn'), so I don't see much practical benefit to
removing 'git' as an input.

Other opinions welcome :)

Mark
M
M
Maxime Devos wrote on 18 May 15:36 +0200
Re: Archived problem report bug#30434 (magit won’t work over TRAMP)
(address . control@debbugs.gnu.org)
77826704875d168a2f7c608e146d9d5b09e7588c.camel@telenet.be
unarchive 30434
reopen 30434
thanks
-----BEGIN PGP SIGNATURE-----

iI0EABYKADUWIQTB8z7iDFKP233XAR9J4+4iGRcl7gUCYoT2QhccbWF4aW1lZGV2
b3NAdGVsZW5ldC5iZQAKCRBJ4+4iGRcl7lQ1AQCOb+crMXrPng1PpUFm2GtiJAio
jQLpGf6HIO90ixSmYAEA85ZY/XxHsRDDGp+x1f28SqVS+FgJ9j/ejl2EWp3bmgI=
=ldjz
-----END PGP SIGNATURE-----


M
M
Maxim Cournoyer wrote on 13 Jul 14:53 +0200
Re: bug#30434: magit won’t work over TRAMP
(name . Maxime Devos)(address . maximedevos@telenet.be)
87zghd18du.fsf_-_@gmail.com
Hi Maxime,

Maxime Devos <maximedevos@telenet.be> writes:

Toggle quote (4 lines)
> unarchive 30434
> reopen 30434
> thanks

Why did you reopen that issue? Does the original problem still affect
you (a hard-coded magit-git-executable causing problems when executed on
remote machines via TRAMP).

Thanks,

Maxim
M
M
Maxime Devos wrote on 20 Jul 17:42 +0200
(name . Maxim Cournoyer)(address . maxim.cournoyer@gmail.com)
f774739e-c635-3e14-2298-af53b06b69ac@telenet.be
On 13-07-2022 14:53, Maxim Cournoyer wrote:
Toggle quote (14 lines)
> Hi Maxime,
>
> Maxime Devos <maximedevos@telenet.be> writes:
>
>> unarchive 30434
>> reopen 30434
>> thanks
> Why did you reopen that issue? Does the original problem still affect
> you (a hard-coded magit-git-executable causing problems when executed on
> remote machines via TRAMP).
>
> Thanks,
>
> Maxim
Looks like my original reply didn't come through because the archival,
so I sent an unarchive+reopen but forgot to send the actual message
again ... here it is:
Toggle quote (16 lines)
> Nowadays 'magit' has a separate magit-git-executable:
>
> "The Git executable used by Magit on the local host.
> On remote machines `magit-remote-git-executable' is used instead."
>
> and magit-remote-git-executable:
>
> (defcustom magit-remote-git-executable "git"
> "The Git executable used by Magit on remote machines.
> On the local host `magit-git-executable' is used instead.
> Consider customizing `tramp-remote-path' instead of this
> option."
>
> so maybe this patch can now be reversed, such that emacs-magit
> can be used without depending on the (possibly non-existent) 'git' in
> $PATH? Needs to be verified though.
More concretely, try "guix shell emacs emacs-magit --pure -- emacs"
followed by "M-x magit-status" in a Git checkout, it will fail due to
not finding the 'git' executable.
So my idea is to use the new magit changes to both make the remote TRAMP
work and _also_ make local things work in a pure environment, undoing
the regression that was caused by reverting the
git->/gnu/store/.../bin/git substitution without creating new regressions.
Greetings,
Maxime.
Attachment: OpenPGP_signature
M
M
Maxim Cournoyer wrote on 21 Jul 06:04 +0200
(name . Maxime Devos)(address . maximedevos@telenet.be)(address . 30434@debbugs.gnu.org)
87v8rrqfgp.fsf@gmail.com
Hi Maxime,

Maxime Devos <maximedevos@telenet.be> writes:


[...]

Toggle quote (27 lines)
>> Nowadays 'magit' has a separate magit-git-executable:
>>
>> "The Git executable used by Magit on the local host.
>> On remote machines `magit-remote-git-executable' is used instead."
>>
>> and magit-remote-git-executable:
>>
>> (defcustom magit-remote-git-executable "git"
>> "The Git executable used by Magit on remote machines.
>> On the local host `magit-git-executable' is used instead.
>> Consider customizing `tramp-remote-path' instead of this
>> option."
>>
>> so maybe this patch can now be reversed, such that emacs-magit
>> can be used without depending on the (possibly non-existent) 'git' in
>> $PATH? Needs to be verified though.
>
> More concretely, try "guix shell emacs emacs-magit --pure -- emacs"
> followed by "M-x magit-status" in a Git checkout, it will fail due to
> not finding the 'git' executable.
>
> So my idea is to use the new magit changes to both make the remote
> TRAMP work and _also_ make local things work in a pure environment,
> undoing the regression that was caused by reverting the
> git->/gnu/store/.../bin/git substitution without creating new
> regressions.

Sounds good to me! I'll be happy to review any patch implementing it.

Maxim
?