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.

No, unfortunately not. For my own phone I simply clear unused/old photos every once in a while.

I’d say you are in the right track. My family photo archive is more than 1TB and Nextcloud with Memories handles that just fine. Earlier this year I upgraded my home server from an i3-9100 CPU to a Xeon E-2236 (6 cores/ 12 threads compared to the old 2 cores/ 4 threads). That wasn’t strictly necessary, but it did increase the responsiveness of browsing Memories’ time line. Most of all, it increased the speed at which Recognize processed the images for face and object recognition.

One major thing to test, though, is the Nextcloud iOS client. I have one family member with an iPhone and ipad and the automatic upload only seems to work as long as the Nextcloud app is running in the foreground. Apparently Apple doesn’t allow “foreign” apps to run in the background.

Regarding your point 1 I have no solution. Regarding your point 2, you could just use a shared folder with permissions set correctly. But you could also have a look at the Group Folder functionality.

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.

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.