this post was submitted on 10 Nov 2023
2 points (100.0% liked)

Emacs

310 readers
2 users here now

A community for the timeless and infinitely powerful editor. Want to see what Emacs is capable of?!

Get Emacs

Rules

  1. Posts should be emacs related
  2. Be kind please
  3. Yes, we already know: Google results for "emacs" and "vi" link to each other. We good.

Emacs Resources

Emacs Tutorials

Useful Emacs configuration files and distributions

Quick pain-saver tip

founded 1 year ago
MODERATORS
rglullis
raphael
2
Forge: no longer showing merge request numbers in Magit-log (since quite some time...) (alien.top)
submitted 1 year ago by ph0t0nix@alien.top to c/emacs
7 comments fedilink hide all child comments
 

I have been using Magit and Forge for several years, mainly with projects on self-hosted Gitlab instances. The experience has been great!

One of the nice things that Forge did for me was showing the numbers of merge requests (in !123 form) in my magit-log views. Some time ago, however, this stopped working. Actually, this stopped working quite some time ago, maybe a year or more. I was too lazy to report it and too busy to investigate. IIRC it didn't stop working right away for all repos, so I guess it is not related to e.g. upgrading to Emacs 28 (and it was definitely before I upgraded to Emacs 29.1).

To investigate this in more detail, I created new clones of several projects, but that didn't change anything. I also tried a simplified Emacs config in a new home directory to make sure that Forge's database was created from scratch. Same problem persists.

On Forge's Github pages, I found some references to interactions of Forge with bug-reference-mode, so maybe it somehow has to do with that? On the other hand, given that I used a fresh Emacs config + new clones, I guess this isn't the cause of the issue either.

Does anyone know how to get the MR numbers back in Magit's log view?

top 7 comments
sorted by: hot top controversial new old
[–] troll-gpt@alien.top 1 points 1 year ago (1 children)

Few things to try: is the sql file still there? Did you try forge fetch all issues, maybe you need to re add it to forge, maybe forge is not loaded after opening magit, maybe forge is pointing to another remote which doesn't have issues.

[–] ph0t0nix@alien.top 1 points 1 year ago

Thanks for your reply. Let me clarify one thing: Forge works fine, in general. I can list/fetch/edit issues and merge requests. So I doubt there is a problem with the SQL file. Even more so because I ran my tests in a separate (clean) home directory.

My issue here is that in the (distant) past, whenever I opened the Magit log view with branches (Magit → l → b), I would see the merge request number (e.g. !123) for each merge commit. And now that is no longer that case.

I have tested this with two different self-hosted Gitlab instances.

[–] magthe0@alien.top 1 points 1 year ago (1 children)

IIRC this was actually accomplished using a configuration in the git repo itself. GitHup PR numbers are custom refs, but they aren't included by default on git clone. I don't remember what the refs are called though. Hopefully someone else can help with that.

[–] tarsius_@alien.top 1 points 1 year ago (1 children)

Exactly.

When you add the current repository to the forge database, then that also takes care of adding the appropriate fetch refspecs.

When you remove and then clone again a git repository, which was already being tracked in the forge database, then you don't have to add the repository to the forge database again. But that means that the step where the fetch refspecs are added, also won't be run again.

But you can use M-x forge-add-pullreq-refspec to add them explicitly. Also see the option by the same name.

[–] ph0t0nix@alien.top 1 points 1 year ago (1 children)

Thanks u/magthe0 and u/tarsius_, that rang a bell. Unfortunately, that doesn't seem to be the problem. The refspecs have been added to the .git/config files of the clones (I usually keep my working copies around and rarely clone from scratch).

As a test, I just (freshly) cloned one of my projects in a subdirectory /tmp and indeed, after running M-x forge-add-pullreq-refspec, the following was added to the .git/config file:

       fetch = +refs/merge-requests/*/head:refs/pullreqs/*

for remote origin. This looks fine (and such a line is present in the 'regular' clones of my projects as well). Next, I ran M-x magit-fetch-all, as well as N f f to tell Forge to fetch all topics. The Magit status window shows the "Pull requests" and "Issues" sections and both are populated (with proper !123 type coding for the merge requests). However, when I open the magit log screen I am back where I was before: I don't see the MR numbers as refspecs there (I have the -d Show refnames (--decorate) option turned on.

Side note: I'm not a master of the Git plumbing commands, but git show-ref doesn't seem to list all MRs. For this test project I have 10 MRs (all merged or closed), but only 9 and 10 show up:

$ git show-ref      
f0aa1b61be5ea74c47c473a716f209c698a1a006 refs/heads/master
68e5d70e05fbdc6d47e8cb6da903dcd89d4432ea refs/pullreqs/10
886d7067aa3e609e1b11560a949182dadc57401b refs/pullreqs/9
f0aa1b61be5ea74c47c473a716f209c698a1a006 refs/remotes/origin/HEAD
f0aa1b61be5ea74c47c473a716f209c698a1a006 refs/remotes/origin/master

However, in the Magit status view, I do see the last 5 and M-x forge-list-pullreqs lists them all.

[–] tarsius_@alien.top 1 points 11 months ago (1 children)

This changed with https://github.com/git/git/commit/92156291ca82ae4f4ad09fde8181c5f2b7dba6ca.

You can revert to the old ways with git config --global log.initialDecorationSet all. I'll have to think about how to best deal with that in Magit.

[–] ph0t0nix@alien.top 1 points 11 months ago

Thanks a lot for digging that up, u/tarsius_! In the example repo I mentioned above, I now see MRs !9 and !10 in the Magit log view (well, without the !, but that is fine).

The fact that I don't see older MRs probably has something to do with the corresponding refs not having been downloaded. I'll see if I can figure out how to do that.