Following @algernon’s suggestion, I’m trying forge for magit.
Install it via `M-x package-list-packages`.
My setup is this: my `origin` remote points to my remote git repo. There’s also a `cgit` running on that server, but what I really care about is the alternative `github` remote I have installed. I had to set the name of this remote in a git config option via the command line:
git config --add "forge.remote" "github"
I was told to `M-x forge-pull` when I tried to look at the issues using `' l i`. When I did that, it told me that it was going to create a token in `~/.authinfo` and if I didn’t want that, I’d have to abort and configure `auth-sources`. So I did that:
(setq auth-sources '("~/.authinfo.gpg"))
So I tried again. `forge-pull` said it was going to create a token and save it in `~/.authinfo.gpg` and I agreed. Sadly, it didn’t work:
ghub--handle-response-headers: BUG: missing headers See https://github.com/magit/ghub/issues/81. headers: nil status: nil buffer: #<buffer *http api.github.com:443*> buffer-string: "" --- end of buffer-string ---
I wonder why.
I restarted Emacs. Visited my repo. Ran `magit-status`. Ran `forge-pull`. And got the error: “transient--layout-member: magit-dispatch is not a transient command”.
I have no idea what this means. Fiddled some more, went through the process again, got the missing headers error again. I’m not happy.
Now I’m following the hints in the Ghub manual about manually creating the personal access token I need. Turns out that the token was created on the site, but the line was missing in my `~/.authinfo.gpg`. So no I’m adding it manually.
machine api.github.com login kensanata^forge password *secret*
And I’m still getting the same error.
ghub--handle-response-headers: BUG: missing headers See https://github.com/magit/ghub/issues/81. headers: nil status: nil buffer: #<buffer *http api.github.com:443*> buffer-string: "" --- end of buffer-string ---
Looking at #81 and reading through the entire thread it seems the answer is installing Emacs 27, or using `(setq gnutls-log-level 1)` but “only because it slows things down slightly,” perhaps.
By now I’m sick and tired of the entire thing. I remember why using special clients written to new APIs is a pain. For the moment, this doesn’t seem to be better than using either the websites directly, or an email based git workflow and keeping track of issues elsewhere.
I’m going to drop this for a while.
#Emacs
(Please contact me if you want to remove your comment.)
⁂
Fair enough. But some comments.
When I did that, it told me that it was going to create a token in ~/.authinfo and if I didn’t want that, I’d have to abort and configure auth-sources.
Seems reasonable to inform you that the default is not safe. Since I have no control over the default that’s the best I can do.
BUG: missing headers
There is a severe bug in Emacs and once again this is completely beyond my control. This is going to haunt me forever because it will take half a decade for almost everyone to update to the (as of now unreleased) version of Emacs that fixes that bug.
Turns out that the token was created on the site, but the line was missing in my ~/.authinfo.gpg.
The above bug kicked in at a very unfortunate time. There is no way for me to make this change atomic. Telling Github to create a new token succeeded, but then the bug prevented Emacs from receiving the token and storing it locally.
And got the error: “transient--layout-member: magit-dispatch is not a transient command”.
It means you haven’t updated Magit in a long time. The version you have installed is to old to be compatible with Forge. I have now added some safety-nets that should prevent that when installing Forge from Melpa. It will probably take a few hours for them to become active and won’t help if you have already installed Forge. Just make sure to update Ghub, Magit and Forge to the latest snapshots.
By now I’m sick and tired of the entire thing. I remember why using special clients written to new APIs is a pain.
Fair enough. Though I would like to point out that many of these issues are beyond my control.
For the moment, this doesn’t seem to be better than using either the websites directly, or an email based git workflow and keeping track of issues elsewhere.
The setup process was painful but it would be a shame to give up now. You didn’t actually get a change to see whether the current implementation would already be an improvement for you. (Which it might not, many features are still missing.)
Cheers, Jonas
Ps: I wish bug reports came with such a clear description of what the user tried and how things failed.
– Jonas Bernoulli 2019-04-10 11:08 UTC
---
No worries. I will try again when I get Emacs 27.
– Alex Schroeder 2019-04-10 11:41 UTC