-
Notifications
You must be signed in to change notification settings - Fork 63
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
ghub-http-error 404: Ref not found #308
Comments
For now, you can run |
Does the following not work for you? (Works for me…is in it doesn't signal) (ghubp-get-repos-owner-repo-commits-ref-status
'((name . "evil-collection")
(owner (login . "emacs-evil")))
"show-part-map") |
Have you updated both ghub+ and magithub to the latest versions from MELPA? |
No, actually. Same problem. But could this be the problem? I'm not super familiar with the github API, but when I replace "evil-emacs" with "vodik", it suddenly works. So maybe this is some details that help:
I don't know why magithub is looking at the "evil-emacs" repo though.
Yes, latest releases |
Hm, try wrapping it in (magithub-request
(ghubp-get-repos-owner-repo-commits-ref-status
'((name . "evil-collection")
(owner (login . "emacs-evil")))
"show-part-map")) |
That means the ref exists on your fork, but does not exist on the parent repo. This might be a problem, but it's unrelated to the signal 😄 Perhaps we should be looking to the branch's push remote for statuses, but that's a separate issue. Let's take it one at a time. |
Yeah, same problem with that snippet, again, works when I switch "emacs-evil" with "vodik". But I don't know why magithub is fixated on finding it under the wrong repo. For what its worth, my hunch is something deeper is wrong. The problem has gone away now, but I think its because that PR got merged, so magithub might be partially finding it and misattributing it. Also, for what its worth, I'm seeing a list of open issues, but not the list of open pull requests (upstream repo PRs): |
Make sure you've refreshed the list of issues; we don't retrieve a new list if the cache is populated there. When you say it doesn't work, does it signal? I was getting a value of nil which I understand to be 'working'. The signal is much more worrisome to me. |
Ah, for some reason, I thought it was refreshing while when I was refreshing magit as well.
No signal, but after refreshing, I'm seeing a single PR. I think 2 hours ago there where no open PRs, so smells like its also working for you. So at this point, I don't know what do say. It seems like everything is working, I don't know how I confused magithub about where the remote for my pull request lived, (created from inside magithub) and its honestly been working just fine for other repos I've been using, so I'm at a loss. Time to close this issue? Thank you for your time though. |
Hi, I've been getting the same error and I can reproduce it consistently. If I'm working on a local branch and the remote branch is deleted when I try to get the magit status then the magit-ci-status function fails with a 404 error like the op |
Hmm. That shouldn't be. Likely a bug in ghub+ then. |
I also got an error similar to this by cloning a repository, forking it using Sorry for the garbled backtrace, I'm having trouble pasting it, probably because the byte-compiled output contains \0s or something. I tried to paste it "manually" including the parts that I thought were relevant, but I may have missed something, in which case please let me know and I'll generate another one.
|
I'm seeing something similar with CI statuses. I have |
Hey, so I tried creating a pull request using magithub, and while it worked, afterwards I've been unable to open magit without it crashing.
All I get now in the popup window is just the first three lines, "Head:", "Rebase:", "Push:", and then nothing.
This is the stack trace I got:
The text was updated successfully, but these errors were encountered: