rioritization 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 fix
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
wrote:
More concr
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 wrote:
More concretely, try "guix shell emacs emacs-magit --pure --
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 wrote:
>> More concretely, try "guix shell emacs emacs-magit --pure -- emacs"
>> followed by "M-x magit-status" in a
Hi Maxime,
Maxime Devos 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-remot
On 13-07-2022 14:53, Maxim Cournoyer wrote:
Hi Maxime,
Maxime Devos 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
Hi Maxime,
Maxime Devos 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
Hi Alex,
Alex Kost 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
Mark H Weaver (2018-02-16 04:09 -0500) wrote:
> Alex Kost writes:
>
>> Mark H Weaver (2018-02-14 13:17 -0500) wrote:
>>
>>> Alex Kost 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 belo
Alex Kost writes:
> Mark H Weaver (2018-02-14 13:17 -0500) wrote:
>
>> Alex Kost 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
Mark H Weaver (2018-02-14 13:17 -0500) wrote:
> Hi Alex,
>
> Alex Kost writes:
>
>> Mark H Weaver (2018-02-14 03:51 -0500) wrote:
>>
>>> Ricardo Wurmus writes:
I think it makes sense *not* to hardcode the path to the git executable
here.
>>>
>>> Agreed. Done, in commit 5fe9ba59ba1cea1
Hi Alex,
Alex Kost writes:
> Mark H Weaver (2018-02-14 03:51 -0500) wrote:
>
>> Ricardo Wurmus 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 317e8e9404
Mark H Weaver (2018-02-14 03:51 -0500) wrote:
> Ricardo Wurmus 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
> cor
Ricardo Wurmus 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,
M
Alex Kost 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 us
Alex Kost 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 use
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
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.
Inst
18 matches
Mail list logo
