Make a pull regenerate the Xcode project, so nobody opens a stale one

`FlamenetMessenger.xcodeproj` is generated by xcodegen and is not in git. So
a pull updates `project.yml` and leaves the one file Xcode actually reads
exactly as it was. Everything on disk is correct and the project is a day
old, which is how a stale version number reaches an archive, and how the
owner came to say "i am always looking at a stale project".

`post-merge`, `post-checkout` and `post-rewrite` run the generator, and
`generate.sh` points `core.hooksPath` at them every time it runs, so a fresh
clone picks this up the first time anybody generates rather than needing a
setup step nobody remembers.

It does not help when Xcode already has the project open, because that is
Xcode's cache rather than the file. Closing and reopening is still the answer
there.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>

.githooks/post-checkout

@@ -0,0 +1,15 @@
+#!/usr/bin/env bash
+# Regenerate the Xcode project after anything that can change project.yml.
+#
+# `FlamenetMessenger.xcodeproj` is generated by xcodegen and is not in git, so
+# a pull updates project.yml and leaves the project Xcode opens exactly as it
+# was. That is how a stale version number gets archived: everything on disk is
+# correct and the one file Xcode reads is a day old.
+#
+# Installed by Scripts/generate.sh, which sets core.hooksPath to this
+# directory. Silent when nothing changed.
+set -u
+cd "$(git rev-parse --show-toplevel)" || exit 0
+[ -f project.yml ] || exit 0
+./Scripts/generate.sh >/dev/null 2>&1 && echo "xcodegen: project regenerated"
+exit 0

.githooks/post-merge

@@ -0,0 +1,15 @@
+#!/usr/bin/env bash
+# Regenerate the Xcode project after anything that can change project.yml.
+#
+# `FlamenetMessenger.xcodeproj` is generated by xcodegen and is not in git, so
+# a pull updates project.yml and leaves the project Xcode opens exactly as it
+# was. That is how a stale version number gets archived: everything on disk is
+# correct and the one file Xcode reads is a day old.
+#
+# Installed by Scripts/generate.sh, which sets core.hooksPath to this
+# directory. Silent when nothing changed.
+set -u
+cd "$(git rev-parse --show-toplevel)" || exit 0
+[ -f project.yml ] || exit 0
+./Scripts/generate.sh >/dev/null 2>&1 && echo "xcodegen: project regenerated"
+exit 0

.githooks/post-rewrite

@@ -0,0 +1,15 @@
+#!/usr/bin/env bash
+# Regenerate the Xcode project after anything that can change project.yml.
+#
+# `FlamenetMessenger.xcodeproj` is generated by xcodegen and is not in git, so
+# a pull updates project.yml and leaves the project Xcode opens exactly as it
+# was. That is how a stale version number gets archived: everything on disk is
+# correct and the one file Xcode reads is a day old.
+#
+# Installed by Scripts/generate.sh, which sets core.hooksPath to this
+# directory. Silent when nothing changed.
+set -u
+cd "$(git rev-parse --show-toplevel)" || exit 0
+[ -f project.yml ] || exit 0
+./Scripts/generate.sh >/dev/null 2>&1 && echo "xcodegen: project regenerated"
+exit 0

Scripts/generate.sh

@@ -21,6 +21,18 @@
 # back, so the pin follows the change:
 #
 #   Scripts/generate.sh --update
+
+# Make a pull regenerate this project, so nobody opens a stale one.
+#
+# The project is generated and gitignored, so a pull changes project.yml and
+# leaves the file Xcode reads untouched. That is how a stale version number
+# reaches an archive: everything on disk correct, and the one file Xcode opens
+# a day old. Cheap to set, and setting it every run means a fresh clone gets it
+# the first time anybody generates.
+if [ -d .githooks ] && [ "$(git config core.hooksPath 2>/dev/null)" != ".githooks" ]; then
+  git config core.hooksPath .githooks 2>/dev/null || true
+fi
+
 set -euo pipefail
 
 here="$(cd "$(dirname "${BASH_SOURCE[0]}")/.." && pwd)"