Michael Albinus <[email protected]> writes: > Augusto Stoffel <[email protected]> writes: > >> Hi Michael, > > Hi Augusto, > > Thanks for your answer. I'm adding Jonas to the discussion. > >> On Sun, 25 Oct 2026, Michael Albinus wrote: >> >>> Zach Jibben via <[email protected]> writes: >>> >>> Hi, >>> >>>> This reproduces with `emacs -Q`. >>>> >>>> A value added to a buffer-local `process-environment` is not >>>> propagated to a process executed through TRAMP. >>>> >>>> Steps to reproduce: >>>> >>>> 1. Start: >>>> >>>> emacs -Q >>>> >>>> 2. Visit any directory on an SSH host, for example: >>>> >>>> C-x C-f /ssh:HOST:/tmp/ RET >>>> >>>> 3. Evaluate: >>>> >>>> (let ((dir default-directory) >>>> (env (cons "MAGIT_TRAMP_TEST=yes" process-environment))) >>>> (with-temp-buffer >>>> (setq default-directory dir) >>>> (setq-local process-environment env) >>>> (process-file "sh" nil t nil "-c" >>>> "printf '%s' \"$MAGIT_TRAMP_TEST\"") >>>> (buffer-string))) >>>> >>>> Expected result: >>>> >>>> "yes" >>>> >>>> Actual result: >>>> >>>> "" >>>> >>>> This appears to be a regression related to commit >>>> 8f5b786cacbc5e85a71b1e2ec530db9feb41e73c >>>> ("Check buffer-local value in tramp-local-environment-variable-p"). >>>> >>>> I encountered this through Magit. Magit uses a buffer-local >>>> process-environment containing GIT_INDEX_FILE while constructing >>>> a temporary index for `magit-stash-both`. Because GIT_INDEX_FILE >>>> is not propagated to the remote Git process, Magit can create an >>>> incomplete stash and subsequently discard unstaged changes. >>>> >>>> Historically, Magit issue #4160 involved essentially the same >>>> failure mode when GIT_INDEX_FILE was lost across process buffers. >>>> >>>> As a test/workaround, forcing >>>> `tramp-local-environment-variable-p` to return nil for Magit's >>>> temporary GIT_INDEX_FILE causes Magit stashing over TRAMP to work >>>> correctly again. >>> >>> This change was triggered by bug#81175. Unfortunately, this bug report >>> doesn't contain a reasoning for the change. Augusto, could you, pls >>> provide details? >> >> The goal of bug#81175 was to make Tramp not bleed env vars to the remote >> host that have been set by packages such as envrc or buffer-env. >> >> The manual says: >> >> TRAMP does not use the defaults specified in process-environment for >> running process-file or start-file-process on remote hosts. When >> values from process-environment are needed for remote processes, >> then set them as follows: >> >> (let ((process-environment (cons "HGPLAIN=1" process-environment))) >> (process-file …))
Magit uses `with-environment-variables', which adds a lot of complexity but as far as I can tell ends up doing "the same thing" (but it doesn't reuse the old list). Am I wrong about that? How does what Magit is doing differ from what it is supposed to do instead? >> We could clarify "defaults" in that paragraph, Please also clarify what it uses instead. >> but Magit is not >> following the standard Tramp-compatible procedure for passing special >> env vars to a subprocess. What is the standard Tramp-compatible procedure? >> I'd say it's a Magit bug. The docstring of with-environment-variables does not mention that it cannot be used for functionality that a user might possibly use over Tramp (so essentially everything) and what to do instead. After looking at "Integration with other Emacs packages", I am under the impression, that I have to implement my own variant of `with-environment-variables', which not just binds a modified `process-environment`, but does the same for `tramp-remote-process-environment'. I feel I am being told that I am "holding it wrong". Maybe `with-environment-variables' should be changed to do that by default? Or maybe it VARIABLES should have the form (VAR VALUE [ALSO-DO-IT-FOR-TRAMP])? Or maybe Emacs/Tramp should provide such a macro (mentioned in the docstring of `with-environment-variables'? >>> Thanks, and best regards, Michael. Michael, I need more guidance. Thanks. Jonas
