ci: Update git index before trying dist

Of course, after having tested dist-job and demonstrated that it works,
I then tried to make a release and it was just as broken as before.

After some digging into the Meson source, it seems that recent versions
of Meson (≥1.5.0) have added a change to update the git index before
checking whether it’s dirty, as apparently stat changes on files in the
working tree can otherwise make files look dirty — but they won’t appear
in `git status` output because it updates the index before outputting.

The Meson code to check the git index hasn’t changed for a long time, so
perhaps there’s been a recent change in GitLab which causes stat changes
on files in the working tree, if the checkout is a release tag*, and
this triggered the latent Meson bug which we still have because we’re
using an older Meson version (1.4.x)?

I’m desperate and I’ll try this and see if it works. As my failures pile
up, you’ll see that reflected in the micro version number.

* My testing has shown that whether dist-job fails is not related to:
 - The repository/fork (origin/pwithnall)
 - The CI runner running the job
 - The git strategy (clone/fetch) (so the previous commit is probably
   useless)
 - The number of retries (it doesn’t seem to be a race)

The only remaining difference I can think of between succeeding and
failing dist-job runs is that the failing ones are on a signed git tag.
Unfortunately, due to the restrictions we have on creating and deleting
tags, this is very hard to test.

This whole experience continues to be very frustrating.

Signed-off-by: Philip Withnall <pwithnall@gnome.org>

.gitlab-ci.yml

@@ -997,6 +997,20 @@ dist-job:
             -Dintrospection=enabled
             -Dman-pages=enabled
             _build
+    # FIXME: This workaround can be dropped once we depend on Meson 1.6.0.
+    # dist-job has a history of failing with a 'dirty tree' error for occult reasons.
+    # This might be related to Meson commits c9aa4aff66 and e9037e7b9f, which
+    # indicate that Meson’s dirty tree check can be fooled by an updated timestamp
+    # on a file in the working tree, even if its content hasn’t changed. Perhaps
+    # sometime recently, GitLab has started changing the stat of files in the
+    # git tree when it didn’t previously (as the same Meson implementation
+    # previously worked fine).
+    - git update-index -q --refresh
+    # Potentially helpful debug output related to the above workaround
+    - git diff-index HEAD
+    - git status
+    - git submodule status
+    # Actually run the dist
     - meson dist -C _build
     # Compile again to build the docs
     - meson compile -C _build