Git warning: "Empty last update token." - windows

Question

What is the cause and resolution for the git warning message "Empty last update token."?
I have a repository, where every command prints this warning, e.g.
$ git status
warning: Empty last update token.
On branch foo
Your branch is up to date with 'origin/foo'.
$ git fetch
warning: Empty last update token.
$ git reset --hard
warning: Empty last update token.
Updating files: 100% (79/79), done.
HEAD is now at e1c42a2 blah
$ git prune
warning: Empty last update token.
The commands still seem to succeed. The warning message totally confuses external tools like git-extensions though, which shows "unresolved merge conflicts" when git status contains any unexpected output.
The problem only occurs with the local repository on one specific pc, but copying the .git folder to a different pc reproduces the problem.
I could delete the local copy and start fresh, but I would like to determine the cause, and perhaps even save the stashes.

Answer 1

#kaveman is right, this is evidently the new filesystem monitoring daemon that got built into git for Windows and Mac OS in 2.37. When I enabled with core.fsMonitor = true in my .gitconfig, git 2.35.1 printed this same Empty last update token warning. After I upgraded to git 2.37, the warning disappeared.

Answer 2

This isn't a great answer, but it got rid of the error message for me:
Check if core.fsMonitor is on:
$ git config core.fsMonitor
true
And if true, turn it off:
$ git config core.fsMonitor false
$ git config core.fsMonitor
false
Potentially more information on this thread: https://public-inbox.org/git/4aa1293e-00b6-b9ef-efd4-cdf605db37a1#jeffhostetler.com/

Answer 3

Note: on Mac, fsmonitor might work better with Git 2.39 (Q4 2022): by default, use of fsmonitor on a repository on networked filesystem is disabled.
Add knobs to make it workable on macOS.
See commit c4f9490 (10 Oct 2022) by Jeff King (peff).
See commit 5aa9e32, commit 25c2cab, commit 12fd27d, commit 8f44976, commit 6beb268, commit 508c1a5 (04 Oct 2022) by Eric DeCosta (edecosta-mw).
(Merged by Junio C Hamano -- gitster -- in commit 7b8cfe3, 17 Oct 2022)
fsmonitor: deal with synthetic firmlinks on macOS
Signed-off-by: Eric DeCosta
Starting with macOS 10.15 (Catalina), Apple introduced a new feature called 'firmlinks' in order to separate the boot volume into two volumes, one read-only and one writable but still present them to the user as a single volume.
Along with this change, Apple removed the ability to create symlinks in the root directory and replaced them with 'synthetic firmlinks'.
See 'man synthetic.conf'
When FSEevents reports the path of changed files, if the path involves a synthetic firmlink, the path is reported from the point of the synthetic firmlink and not the real path.
For example:
Real path: /System/Volumes/Data/network/working/directory/foo.txt
Synthetic firmlink: /network -> /System/Volumes/Data/network
FSEvents path: /network/working/directory/foo.txt
This causes the FSEvents path to not match against the worktree directory.
There are several ways in which synthetic firmlinks can be created: they can be defined in /etc/synthetic.conf, the automounter can create them, and there may be other means.
Simply reading /etc/synthetic.conf is insufficient.
No matter what process creates synthetic firmlinks, they all get created in the root directory.
Therefore, in order to deal with synthetic firmlinks, the root directory is scanned and the first possible synthetic firmink that, when resolved, is a prefix of the worktree is used to map FSEvents paths to worktree paths.
In addition, Git 2.39 (Q4 2022) also enables macOS build with sha1dc hash function.
See commit 3220565 (19 Oct 2022) by Ævar Arnfjörð Bjarmason (avar).
(Merged by Junio C Hamano -- gitster -- in commit cc75743, 21 Oct 2022)
fsmonitor OSX: compile with DC_SHA1=YesPlease
Signed-off-by: Eric DeCosta
Signed-off-by: Ævar Arnfjörð Bjarmason
As we'll address in subsequent commits the "DC_SHA1=YesPlease" is not on by default on OSX, instead we use Apple Common Crypto's SHA-1 implementation.
In 6beb268 ("fsmonitor: relocate socket file if .git directory is remote", 2022-10-04, Git v2.39.0 -- merge listed in batch #3) the build was broken with "DC_SHA1=YesPlease" (and probably other non-"APPLE_COMMON_CRYPTO" SHA-1 backends).
So let's extract the fix for this from this thread to get the build working again with "DC_SHA1=YesPlease".
In addition to the fix in [1] we also need to replace "SHA_DIGEST_LENGTH" with "GIT_MAX_RAWSZ".
Actually, still with 2.39 (Q4 2022), DC_SHA1 is the default:
See commit d00fa55, commit fb8d7ad, commit dc1cf35, commit ed605fa, commit 84d71c2, commit f569897, commit 34b660e, commit b425ba2, commit 0ced11d, commit e47913e (07 Nov 2022) by Ævar Arnfjörð Bjarmason (avar).
(Merged by Taylor Blau -- ttaylorr -- in commit e53598a, 18 Nov 2022)
Makefile: document default SHA-1 backend on OSX
Signed-off-by: Ævar Arnfjörð Bjarmason
Signed-off-by: Taylor Blau
Since [1] the default SHA-1 backend on OSX has been APPLE_COMMON_CRYPTO.
Per [2] we'll skip using it on anything older than Mac OS X 10.4 "Tiger"[3].
When "DC_SHA1" was made the default in [4] this interaction between it and APPLE_COMMON_CRYPTO seems to have been missed in.
Ever since DC_SHA1 was "made the default" we've still used Apple's CommonCrypto instead of sha1collisiondetection on modern versions of Darwin and OSX.
6106795 (cache.h: eliminate SHA-1 deprecation warnings on Mac OS X, 2013-05-19, Git v1.8.4-rc0 -- merge) (cache.h: eliminate SHA-1 deprecation warnings on Mac
OS X, 2013-05-19)
9c7a0be (config.mak.uname: set NO_APPLE_COMMON_CRYPTO on older systems, 2014-08-15, Git v2.2.0-rc0 -- merge) (config.mak.uname: set NO_APPLE_COMMON_CRYPTO on older
systems, 2014-08-15)
We could probably drop "NO_APPLE_COMMON_CRYPTO", as nobody's likely
to care about such on old version of OSX anymore. But let's leave that
for now.
e6b07da ("Makefile: make DC_SHA1 the default", 2017-03-17, Git v2.13.0-rc0 -- merge listed in batch #7)
Still on the MacOS side, Git 2.40 (Q1 2023) will stop using deprecated macOS API in fsmonitor.
See commit b022600 (14 Dec 2022) by Jeff Hostetler (Jeff-Hostetler).
(Merged by Junio C Hamano -- gitster -- in commit 636de95, 19 Dec 2022)
fsmonitor: eliminate call to deprecated FSEventStream function
Signed-off-by: Jeff Hostetler
Replace the call to FSEventStreamScheduleWithRunLoop() function with the suggested FSEventStreamSetDispatchQueue() function.
The MacOS version of the builtin FSMonitor feature uses the FSEventStreamScheduleWithRunLoop() function to drive the event loop and process FSEvents from the system.
This routine has now been deprecated by Apple.
The MacOS 13 (Ventura) compiler tool chain now generates a warning when compiling calls to this function.
In DEVELOPER=1 mode, this now causes a compile error.
The FSEventStreamSetDispatchQueue() function is conceptually similar and is the suggested replacement.
However, there are some subtle thread-related differences.
Previously, the event stream would be processed by the fsm_listen__loop() thread while it was in the CFRunLoopRun() method.
(Conceptually, this was a blocking call on the lifetime of the event stream where our thread drove the event loop and individual events were handled by the fsevent_callback().)
With the change, a "dispatch queue" is created and FSEvents will be processed by a hidden queue-related thread (that calls the fsevent_callback() on our behalf).
Our fsm_listen__loop() thread maintains the original blocking model by waiting on a mutex/condition variable pair while the hidden thread does all of the work.
While the deprecated API used by the original were introduced in macOS 10.5 (Oct 2007), the API used by the updated code were introduced back in macOS 10.6 (Aug 2009) and has been available since then.
So this change could break those who have happily been using 10.5 (if there were such people), but these two dates both predate the oldest versions of macOS Apple seems to support anyway, so we should be safe.
With Git 2.40 (Q1 2023), use the SHA1DC implementation on macOS, just like other platforms, by default.
See commit 35898ad (15 Dec 2022) by Ævar Arnfjörð Bjarmason (avar).
(Merged by Junio C Hamano -- gitster -- in commit cd2cc44, 26 Dec 2022)
Makefile: use sha1collisiondetection by default on OSX and Darwin
Signed-off-by: Ævar Arnfjörð Bjarmason
When the sha1collisiondetection library was added and made the default in [1] the interaction with APPLE_COMMON_CRYPTO added in [2] and [3] seems to have been missed.
On modern OSX and Darwin we are able to use Apple's CommonCrypto both for SHA-1, and as a generic (but partial) OpenSSL replacement.
This left OSX and Darwin without protection against the SHAttered attack when building Git in its default configuration.
Let's also use sha1collisiondetection on OSX, to do so we'll need to split up the "APPLE_COMMON_CRYPTO" flag into that flag and a new "APPLE_COMMON_CRYPTO_SHA1".
Because of this we can stop conflating whether we want to use Apple's CommonCrypto at all, and whether we want to use it for SHA-1.
This makes the CI recipe added in [4] simpler.
e6b07da ("Makefile: make DC_SHA1 the default", 2017-03-17, Git v2.13.0-rc0 -- merge listed in batch #7)
4dcd773 ("Makefile: add support for Apple CommonCrypto facility", 2013-05-19, Git v1.8.4-rc0 -- merge)
6106795 ("cache.h: eliminate SHA-1 deprecation warnings on Mac OS X", 2013-05-19, Git v1.8.4-rc0 -- merge)
1ad5c3d (ci: use DC_SHA1=YesPlease on osx-clang job for CI, 2022-10-20, Git v2.39.0-rc0 -- merge listed in batch #6)