* bug#30434: magit won’t work over TRAMP @ 2018-02-12 12:53 ` Ricardo Wurmus 2018-02-12 17:33 ` Alex Kost [not found] ` <handler.x.B30434.165288084625349.unknown@debbugs.gnu.org> 0 siblings, 2 replies; 18+ messages in thread From: Ricardo Wurmus @ 2018-02-12 12:53 UTC (permalink / raw) To: 30434 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 https://elephly.net ^ permalink raw reply [flat|nested] 18+ messages in thread
* bug#30434: magit won’t work over TRAMP 2018-02-12 12:53 ` bug#30434: magit won’t work over TRAMP Ricardo Wurmus @ 2018-02-12 17:33 ` Alex Kost 2018-02-12 19:11 ` Ricardo Wurmus 2018-02-12 19:51 ` Mark H Weaver [not found] ` <handler.x.B30434.165288084625349.unknown@debbugs.gnu.org> 1 sibling, 2 replies; 18+ messages in thread From: Alex Kost @ 2018-02-12 17:33 UTC (permalink / raw) To: Ricardo Wurmus; +Cc: 30434 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'. -- Alex ^ permalink raw reply [flat|nested] 18+ messages in thread
* bug#30434: magit won’t work over TRAMP 2018-02-12 17:33 ` Alex Kost @ 2018-02-12 19:11 ` Ricardo Wurmus 2018-02-14 8:51 ` Mark H Weaver 2018-02-12 19:51 ` Mark H Weaver 1 sibling, 1 reply; 18+ messages in thread From: Ricardo Wurmus @ 2018-02-12 19:11 UTC (permalink / raw) To: Alex Kost; +Cc: 30434 Alex Kost <alezost@gmail.com> writes: > 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 https://elephly.net ^ permalink raw reply [flat|nested] 18+ messages in thread
* bug#30434: magit won’t work over TRAMP 2018-02-12 19:11 ` Ricardo Wurmus @ 2018-02-14 8:51 ` Mark H Weaver 2018-02-14 17:00 ` Alex Kost 0 siblings, 1 reply; 18+ messages in thread From: Mark H Weaver @ 2018-02-14 8:51 UTC (permalink / raw) To: Ricardo Wurmus; +Cc: Alex Kost, 30434-done 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. Thanks, Mark ^ permalink raw reply [flat|nested] 18+ messages in thread
* bug#30434: magit won’t work over TRAMP 2018-02-14 8:51 ` Mark H Weaver @ 2018-02-14 17:00 ` Alex Kost 2018-02-14 18:17 ` Mark H Weaver 0 siblings, 1 reply; 18+ messages in thread From: Alex Kost @ 2018-02-14 17:00 UTC (permalink / raw) To: 30434 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. -- Alex ^ permalink raw reply [flat|nested] 18+ messages in thread
* bug#30434: magit won’t work over TRAMP 2018-02-14 17:00 ` Alex Kost @ 2018-02-14 18:17 ` Mark H Weaver 2018-02-15 19:38 ` Alex Kost 0 siblings, 1 reply; 18+ messages in thread From: Mark H Weaver @ 2018-02-14 18:17 UTC (permalink / raw) To: Alex Kost; +Cc: 30434 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. Mark --8<---------------cut here---------------start------------->8--- 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 --8<---------------cut here---------------end--------------->8--- ^ permalink raw reply [flat|nested] 18+ messages in thread
* bug#30434: magit won’t work over TRAMP 2018-02-14 18:17 ` Mark H Weaver @ 2018-02-15 19:38 ` Alex Kost 2018-02-16 9:09 ` Mark H Weaver 0 siblings, 1 reply; 18+ messages in thread From: Alex Kost @ 2018-02-15 19:38 UTC (permalink / raw) To: Mark H Weaver; +Cc: 30434 Mark H Weaver (2018-02-14 13:17 -0500) wrote: > 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 ^ permalink raw reply [flat|nested] 18+ messages in thread
* bug#30434: magit won’t work over TRAMP 2018-02-15 19:38 ` Alex Kost @ 2018-02-16 9:09 ` Mark H Weaver 2018-02-16 16:56 ` Alex Kost 0 siblings, 1 reply; 18+ messages in thread From: Mark H Weaver @ 2018-02-16 9:09 UTC (permalink / raw) To: Alex Kost; +Cc: 30434 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. Mark ^ permalink raw reply [flat|nested] 18+ messages in thread
* bug#30434: magit won’t work over TRAMP 2018-02-16 9:09 ` Mark H Weaver @ 2018-02-16 16:56 ` Alex Kost 2018-02-16 19:00 ` Mark H Weaver 0 siblings, 1 reply; 18+ messages in thread From: Alex Kost @ 2018-02-16 16:56 UTC (permalink / raw) To: Mark H Weaver; +Cc: 30434 [-- Attachment #1: Type: text/plain, Size: 1506 bytes --] Mark H Weaver (2018-02-16 04:09 -0500) wrote: > 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: https://github.com/magit/magit/commit/bf71241122e1a0bf707913c87493214ceb12f588 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): https://github.com/magit/magit/commit/20ebb99a1dda085dfde99bf26d4d8a52fba51bcf Finally the campaign code was removed 2 weeks later: https://github.com/magit/magit/commit/4a9d9e59806735100b5d20a8be32defefb659a33 [-- Warning: decoded text below may be mangled, UTF-8 assumed --] [-- Attachment #2: my-magit.scm --] [-- Type: text/x-scheme, Size: 1703 bytes --] (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)")))) ^ permalink raw reply [flat|nested] 18+ messages in thread
* bug#30434: magit won’t work over TRAMP 2018-02-16 16:56 ` Alex Kost @ 2018-02-16 19:00 ` Mark H Weaver 0 siblings, 0 replies; 18+ messages in thread From: Mark H Weaver @ 2018-02-16 19:00 UTC (permalink / raw) To: Alex Kost; +Cc: 30434 Hi Alex, Alex Kost <alezost@gmail.com> writes: > 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 ^ permalink raw reply [flat|nested] 18+ messages in thread
* bug#30434: magit won’t work over TRAMP 2018-02-12 17:33 ` Alex Kost 2018-02-12 19:11 ` Ricardo Wurmus @ 2018-02-12 19:51 ` Mark H Weaver 1 sibling, 0 replies; 18+ messages in thread From: Mark H Weaver @ 2018-02-12 19:51 UTC (permalink / raw) To: Alex Kost; +Cc: 30434 Alex Kost <alezost@gmail.com> writes: > 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 ^ permalink raw reply [flat|nested] 18+ messages in thread
[parent not found: <handler.x.B30434.165288084625349.unknown@debbugs.gnu.org>]
[parent not found: <77826704875d168a2f7c608e146d9d5b09e7588c.camel@telenet.be>]
* bug#30434: magit won’t work over TRAMP [not found] ` <77826704875d168a2f7c608e146d9d5b09e7588c.camel@telenet.be> @ 2022-07-13 12:53 ` Maxim Cournoyer 2022-07-20 15:42 ` Maxime Devos 0 siblings, 1 reply; 18+ messages in thread From: Maxim Cournoyer @ 2022-07-13 12:53 UTC (permalink / raw) To: Maxime Devos; +Cc: 30434, control 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 ^ permalink raw reply [flat|nested] 18+ messages in thread
* bug#30434: magit won’t work over TRAMP 2022-07-13 12:53 ` Maxim Cournoyer @ 2022-07-20 15:42 ` Maxime Devos 2022-07-21 4:04 ` Maxim Cournoyer 0 siblings, 1 reply; 18+ messages in thread From: Maxime Devos @ 2022-07-20 15:42 UTC (permalink / raw) To: Maxim Cournoyer; +Cc: 30434, control [-- Attachment #1.1.1: Type: text/plain, Size: 1672 bytes --] 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. [-- Attachment #1.1.2: OpenPGP public key --] [-- Type: application/pgp-keys, Size: 929 bytes --] [-- Attachment #2: OpenPGP digital signature --] [-- Type: application/pgp-signature, Size: 236 bytes --] ^ permalink raw reply [flat|nested] 18+ messages in thread
* bug#30434: magit won’t work over TRAMP 2022-07-20 15:42 ` Maxime Devos @ 2022-07-21 4:04 ` Maxim Cournoyer 2023-09-21 7:34 ` Simon Tournier 0 siblings, 1 reply; 18+ messages in thread From: Maxim Cournoyer @ 2022-07-21 4:04 UTC (permalink / raw) To: Maxime Devos; +Cc: 30434 Hi Maxime, Maxime Devos <maximedevos@telenet.be> writes: [...] >> 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 ^ permalink raw reply [flat|nested] 18+ messages in thread
* bug#30434: magit won’t work over TRAMP 2022-07-21 4:04 ` Maxim Cournoyer @ 2023-09-21 7:34 ` Simon Tournier 2023-09-23 10:17 ` Maxime Devos 0 siblings, 1 reply; 18+ messages in thread From: Simon Tournier @ 2023-09-21 7:34 UTC (permalink / raw) To: Maxim Cournoyer; +Cc: 30434, Maxime Devos Hi, This bug#30434 [1] had been closed on 14 Feb 2018 and then reopened on 18 May 2022. 1: https://issues.guix.gnu.org/issue/30434 On Thu, 21 Jul 2022 at 00:04, Maxim Cournoyer <maxim.cournoyer@gmail.com> wrote: >> 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. Now, we are 1 year, 17 weeks, 6 later after this message. So I propose to close this issue and then open another one for this potential patch. WDYT? Cheers, simon ^ permalink raw reply [flat|nested] 18+ messages in thread
* bug#30434: magit won’t work over TRAMP 2023-09-21 7:34 ` Simon Tournier @ 2023-09-23 10:17 ` Maxime Devos 2023-09-23 10:19 ` Maxime Devos 2023-09-23 11:47 ` Simon Tournier 0 siblings, 2 replies; 18+ messages in thread From: Maxime Devos @ 2023-09-23 10:17 UTC (permalink / raw) To: Simon Tournier, Maxim Cournoyer; +Cc: 30434 [-- Attachment #1.1.1: Type: text/plain, Size: 1364 bytes --] Op 21-09-2023 om 09:34 schreef Simon Tournier: > Hi, > > This bug#30434 [1] had been closed on 14 Feb 2018 and then reopened on > 18 May 2022. > > 1: https://issues.guix.gnu.org/issue/30434 > > On Thu, 21 Jul 2022 at 00:04, Maxim Cournoyer <maxim.cournoyer@gmail.com> wrote: > >>> 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. > > Now, we are 1 year, 17 weeks, 6 later after this message. So I propose > to close this issue and then open another one for this potential patch. > > WDYT? The time since that message is irrelevant. The bug is still there, so there is no good reason to close it. If the point of closing unresolved bug reports is some kind of prioritization of bug reports, there's tags, severity levels, etc., you can use instead faking a high bug resolving statistics. Best regards, Maxime Devos. [-- Attachment #1.1.2: OpenPGP public key --] [-- Type: application/pgp-keys, Size: 929 bytes --] [-- Attachment #2: OpenPGP digital signature --] [-- Type: application/pgp-signature, Size: 236 bytes --] ^ permalink raw reply [flat|nested] 18+ messages in thread
* bug#30434: magit won’t work over TRAMP 2023-09-23 10:17 ` Maxime Devos @ 2023-09-23 10:19 ` Maxime Devos 2023-09-23 11:47 ` Simon Tournier 1 sibling, 0 replies; 18+ messages in thread From: Maxime Devos @ 2023-09-23 10:19 UTC (permalink / raw) To: Simon Tournier, 30434 [-- Attachment #1.1.1: Type: text/plain, Size: 1583 bytes --] Op 23-09-2023 om 12:17 schreef Maxime Devos: > Op 21-09-2023 om 09:34 schreef Simon Tournier: >> Hi, >> >> This bug#30434 [1] had been closed on 14 Feb 2018 and then reopened on >> 18 May 2022. >> >> 1: https://issues.guix.gnu.org/issue/30434 >> >> On Thu, 21 Jul 2022 at 00:04, Maxim Cournoyer >> <maxim.cournoyer@gmail.com> wrote: >> >>>> 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. >> >> Now, we are 1 year, 17 weeks, 6 later after this message. So I propose >> to close this issue and then open another one for this potential patch. >> >> WDYT? > > The time since that message is irrelevant. The bug is still there, so > there is no good reason to close it. If the point of closing unresolved > bug reports is some kind of prioritization of bug reports, there's tags, > severity levels, etc., you can use instead faking a high bug resolving > statistics. Wait, I misread -- feel free to open that new bug report. I assumed ‘open another one when that potential patch exists’ instead of ‘right now’. [-- Attachment #1.1.2: OpenPGP public key --] [-- Type: application/pgp-keys, Size: 929 bytes --] [-- Attachment #2: OpenPGP digital signature --] [-- Type: application/pgp-signature, Size: 236 bytes --] ^ permalink raw reply [flat|nested] 18+ messages in thread
* bug#30434: magit won’t work over TRAMP 2023-09-23 10:17 ` Maxime Devos 2023-09-23 10:19 ` Maxime Devos @ 2023-09-23 11:47 ` Simon Tournier 1 sibling, 0 replies; 18+ messages in thread From: Simon Tournier @ 2023-09-23 11:47 UTC (permalink / raw) To: Maxime Devos, Maxim Cournoyer; +Cc: 30434 Hi, On Sat, 23 Sep 2023 at 12:17, Maxime Devos <maximedevos@telenet.be> wrote: >>>> 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. For one, this had been corrected by b59b033af3957e0de9a44733e26cbcc7114a4dfb, IMHO. For me, guix shell emacs emacs-magit --pure -- emacs -q -f magit-status just works. >>>> 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. For two, as explained by [1], the case for TRAMP seems handled, no? >>> Sounds good to me! I'll be happy to review any patch implementing it. >> >> Now, we are 1 year, 17 weeks, 6 later after this message. So I propose >> to close this issue and then open another one for this potential patch. >> >> WDYT? > > The time since that message is irrelevant. The bug is still there, so > there is no good reason to close it. Your report (reopened a closed one) is about two issues. Which one is still there? One? Both? None? Having a clear fresh bug report for specific issue makes easier to deal with instead of a lot old thread mixing several issues where some had been already fixed. Somehow, it makes it hard to know what is currently still accurate and what is not, IMHO. > If the point of closing unresolved > bug reports is some kind of prioritization of bug reports, there's tags, > severity levels, etc., you can use instead faking a high bug resolving > statistics. The point is to have an actionable bug tracker and not some spaghetti thread where it is hard to follow between the still accurate and the already fixed. Ricardo opened an issue tracked as #30434. Subject: bug#30434: magit won’t work over TRAMP Date: Mon, 12 Feb 2018 13:53:22 +0100 (5 years, 31 weeks, 5 days ago) Closed by Mark with the message: Agreed. Done, in commit 5fe9ba59ba1cea12a70d011aacbace52e3bfda18 on master and commit 317e8e9404058af35d9843e076934560f95d895a on core-updates. I'm closing this bug now. Date: Wed, 14 Feb 2018 08:52:02 +0000 (5 years, 31 weeks, 3 days ago) And the discussion ends on: Date: Fri, 16 Feb 2018 14:00:50 -0500 (5 years, 31 weeks, 1 day ago) Then, years later you unarchive and reopen. Date: Wed, 18 May 2022 15:36:02 +0200 (1 year, 18 weeks, 1 day ago) unarchive 30434 reopen 30434 directly followed by Maxim’s question: 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). And this bug was still open just as a reminder waiting for your patch. The initial issue had been closed and what you are reporting is not an issue anymore, from my understanding. I am proposing to open a fresh issue with accurate information from current Guix revisions about what you consider is this bug – referencing to this one if needed. BTW, for what it is worth, I feel your tone arrogant and that is generating an atmosphere that does not make the collaboration friendly. Cheers, simon 1: [bug#59253] [PATCH] gnu: emacs-magit: Substitute git executable path. Kyle Meyer <kyle@kyleam.com> Mon, 14 Nov 2022 19:52:36 -0500 id:87cz9pvy23.fsf@kyleam.com https://issues.guix.gnu.org//59253 https://issues.guix.gnu.org/msgid/87cz9pvy23.fsf@kyleam.com https://yhetil.org/guix/87cz9pvy23.fsf@kyleam.com ^ permalink raw reply [flat|nested] 18+ messages in thread
end of thread, other threads:[~2023-09-23 11:48 UTC | newest] Thread overview: 18+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- [not found] <365299e60040c03a84cbb7770adb3f94349dd2ed.camel@telenet.be> 2018-02-12 12:53 ` bug#30434: magit won’t work over TRAMP Ricardo Wurmus 2018-02-12 17:33 ` Alex Kost 2018-02-12 19:11 ` Ricardo Wurmus 2018-02-14 8:51 ` Mark H Weaver 2018-02-14 17:00 ` Alex Kost 2018-02-14 18:17 ` Mark H Weaver 2018-02-15 19:38 ` Alex Kost 2018-02-16 9:09 ` Mark H Weaver 2018-02-16 16:56 ` Alex Kost 2018-02-16 19:00 ` Mark H Weaver 2018-02-12 19:51 ` Mark H Weaver [not found] ` <handler.x.B30434.165288084625349.unknown@debbugs.gnu.org> [not found] ` <77826704875d168a2f7c608e146d9d5b09e7588c.camel@telenet.be> 2022-07-13 12:53 ` Maxim Cournoyer 2022-07-20 15:42 ` Maxime Devos 2022-07-21 4:04 ` Maxim Cournoyer 2023-09-21 7:34 ` Simon Tournier 2023-09-23 10:17 ` Maxime Devos 2023-09-23 10:19 ` Maxime Devos 2023-09-23 11:47 ` Simon Tournier
Code repositories for project(s) associated with this external index https://git.savannah.gnu.org/cgit/guix.git This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.