On 13-07-2022 14:53, Maxim Cournoyer wrote:
> 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:

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