Commits not showing inside pull requests

[AJCM-git]

I have setup magit and forge correctly, fetched my upstream PRs and issues but for some reason the commits arent showing.
Yes, i have read #320 and tried the solution but it didnt work, running forge-add-pullreq-refspec tells me it is already active and i fetched again just to confirm.
Another weird thing is that the submodule inside my repo can fetch the pull requests and its commits whitout any problems.
I would include a backtrace but there arent any errors to show. If there is any way i can help debug this please tell me

• Emacs 27.1 (using doom emacs)
• Forge repository is set in upstream
• Main config

[remote "upstream"]
	url = [email protected]:space-wizards/space-station-14.git
	fetch = +refs/heads/*:refs/remotes/space-wizards/*
	fetch = +refs/pull/*/head:refs/pullreqs/*
	gh-resolved = base

• submodule that works config

[remote "upstream"]
    url = [email protected]:space-wizards/RobustToolbox.git
    fetch = +refs/heads/*:refs/remotes/space-wizards/*
    fetch = +refs/pull/*/head:refs/pullreqs/*
    gh-resolved = base

[AJCM-git]

sorry for making an issue, saw that the discussion feed was empty and assumed it wasn't used

[tarsius]

Did you use forge to create the issue? That currently only displays the two actual issue templates at the top of what is displayed in the web interface. I am working on fixing that.

I am trying to understand why users keep opening issues for support requests despite my increasingly desperate attempts to get them to notice the instructions that tell them to not do that.

If you used the web interface, then you ignored quite a bit of instructions. Have a careful look: https://github.com/magit/forge/issues/new/choose.

If you used forge, then you still ignored

[Feature request] Suggest a new feature. ⚠ PLEASE DO NOT USE THIS FOR SUPPORT REQUESTS. ⚠

Do you have any suggestions on how to get people to notice and follow these instructions?

[AJCM-git]

Yes i did notice the send requests support templates, the thing is that i assumed it was abandoned/unused because there were no conversations (not even answered) and saw a couple issues somewhat recent with the support label. This summed with the fact that the discussion feature of github is barely used and that i assumed that the issue template was always there but people still asked questions and got labeled with the support label somewhat recently made me commit the mistake.
It was 100% my fault but i think i wouldnt have made this mistake if there were any resolved/active discussions or the issue template SUPPORT ☛ The Discussions feature of this repository had a "[NEW]" before it or something indicating it was a new addition to the template (i guess changing the support label to "support obsolete" or something like that could help too)

[tarsius]

These are good suggestions, though now that there actually are some "discussions" this might not be necessary anymore. Well see, at least the [NEW] sounds like a nice hack. 😀

[tarsius]

Did you read https://magit.vc/manual/forge/Repository-Detection.html, specifically the part about forge.remote? Try setting that.

You might also want to name the "upstream" remote origin. See https://magit.vc/manual/magit/The-Two-Remotes.html.

[AJCM-git]

yes, i have

[forge]
	remote = upstream

in both main and submodule git configs

Changing the name did work! and its nice to have this option. But i would really hate to stick to this naming convention or having to snowflake this specific config (because this naming convention feels very counter-intuitive to me)
Now i know that the forge.remote was set correctly and it should have worked and pulled the commits, can i say that this is a bug?, if there are ways that i can provide more info or help debug this please tell me, i really would like to see the "change upstream remote name" working for me.

Also t the commits are acting very weird, like a recently opened PR with just 1 commit in github will appear as having 15 commits in forge. I think its pulling all the commits since the fork/branch was made or something like that? im not really sure, please tell me if there have been issues like this in the past

[tarsius]

This response is ambiguous to the point where I cannot tell what you are trying to say. For example you appear to be saying that you already had forge.remote=upstream and when you "changed" it to this same value, then things magically started to work. Also it sounds like you are saying that you find your own naming conventions very counter-intuitive, which obviously cannot be what you meant, but all this really throws me off.

I assume you want your own fork to be named "origin" and the official repository by the maintainers of the project "upstream". Many people do that and I think it is because they are accustomed to running git clone git@my-own-fork because that gets them going the fastest. They then end up with their own fork being named "origin" (which I feel makes no sense at all) and resort to using "upstream" for the official repository.

IMO even though that is a common mistake, it still is a mistake. It does not make sense to call a fork the "origin" because that would contradict the common meaning of that word. You are welcome to stick to it, but then you have to set forge.remote to upstream. If you always follow this naming convention, then you only have to set this option once, globally.

Also t the commits are acting very weird, like a recently opened PR with just 1 commit in github will appear as having 15 commits in forge. I think its pulling all the commits since the fork/branch was made or something like that?

The commits that are reachable from the respective refs/pullreqs/N but not from the branch into which that is supposed to be merged are shown. If that branch is somehow behind on your machine, then more commits will be shown. This is how the commits to be shown are determined:

(defun forge--pullreq-range (pullreq &optional endpoints)
  (when-let ((head (forge--pullreq-ref pullreq)))
    (concat (forge--get-remote) "/" (oref pullreq base-ref)
            (if endpoints "..." "..")
            head)))

Ah wait. Your remote tracking refs for upstream are named refs/remotes/space-wizards/*. While technically allowed by Git, it is highly unusual to not use the name of the remote in the name of the remote tracking refs. Because it is so unusual and would be a lot of work to support, Forge does not support it (instead it uses (concat (forge--get-remote) "/" ....) as shown above).

[AJCM-git]

This response is ambiguous to the point where I cannot tell what you are trying to say.

Sorry for the bad response, wrote that when half-sleep.

you appear to be saying that you already had forge.remote=upstream and when you "changed" it to this same value, then things magically started to work. Also it sounds like you are saying that you find your own naming conventions very counter-intuitive, which obviously cannot be what you meant, but all this really throws me off.

What i meant to say is that i already had forge.remote set to upstream as shown in the code block, but after removing that and renaming my upstream to origin and my vice versa the commits starting appearing. What i meant to say with my message is that even though this option is available i would like to use my own naming convention since forge supports that. update: i can use it, see the end of this post

I assume you want your own fork to be named "origin" and the official repository by the maintainers of the project "upstream".

That is correct

IMO even though that is a common mistake, it still is a mistake. It does not make sense to call a fork the "origin" because that would contradict the common meaning of that word. You are welcome to stick to it, but then you have to set forge.remote to upstream. If you always follow this naming convention, then you only have to set this option once, globally.

While i get that it can be confusing and the convention is probably more clearer, its sadly an habit of mine that i have yet to change and if forge supports following my own naming then i would like to use that.
Just to clarify more, the problem is that even though i have my forge.remote set to upstream and upstream is the repo that i forked with all the PRs and issues, when going into the PRs the commits dont appear. Using the two remotes convention makes all of this work and i can see the commits in the PRs update: this is no bug, its me being stupid, see the end of the post

Ah wait. Your remote tracking refs for upstream are named refs/remotes/space-wizards/*.

OH MY GOD. this was it!, i changed it to +refs/heads/*:refs/remotes/upstream/* and now everything works, PRs have commits, the commit count is normal (1 commit shown in github, 1 commit shown in forge), and i even have the "unpulled from upstream/master" section now. thanks for the solution.

While technically allowed by Git, it is highly unusual to not use the name of the remote in the name of the remote tracking refs.

Weird, i think i did that because i saw that in a stack exchange / git guide, should be added to the FAQ in my opinion.

Can you make another post with the solution so i can mark it as the answer?

[AJCM-git]

As tarsius said in #338 (reply in thread) , the problem was that forge doesnt really support remote tracking refs for upstream that are named +refs/remotes/repo-name/* because its an uncommon format, instead you should use +refs/heads/*:refs/remotes/upstream/*