revert(3p/git): Revert merge of git upstream at v2.26.2 r/852

This causes cgit to serve error pages, which is undesirable.

This reverts commit 5229c9b232de5bfa959ad6ebbb4c8192ac513352, reversing
changes made to f2b211131f2347342dde63975b09cf603149f1a3.

1 files changed, 7 insertions, 16 deletions

diff --git a/third_party/git/refs/packed-backend.c b/third_party/git/refs/packed-backend.c
index 4458a0f69ccb..c01c7f5901a6 100644
--- a/third_party/git/refs/packed-backend.c
+++ b/third_party/git/refs/packed-backend.c
@@ -1012,23 +1012,14 @@ int packed_refs_lock(struct ref_store *ref_store, int flags, struct strbuf *err)
 	}
 
 	/*
-	 * There is a stat-validity problem might cause `update-ref -d`
-	 * lost the newly commit of a ref, because a new `packed-refs`
-	 * file might has the same on-disk file attributes such as
-	 * timestamp, file size and inode value, but has a changed
-	 * ref value.
-	 *
-	 * This could happen with a very small chance when
-	 * `update-ref -d` is called and at the same time another
-	 * `pack-refs --all` process is running.
-	 *
-	 * Now that we hold the `packed-refs` lock, it is important
-	 * to make sure we could read the latest version of
-	 * `packed-refs` file no matter we have just mmap it or not.
-	 * So what need to do is clear the snapshot if we hold it
-	 * already.
+	 * Now that we hold the `packed-refs` lock, make sure that our
+	 * snapshot matches the current version of the file. Normally
+	 * `get_snapshot()` does that for us, but that function
+	 * assumes that when the file is locked, any existing snapshot
+	 * is still valid. We've just locked the file, but it might
+	 * have changed the moment *before* we locked it.
 	 */
-	clear_snapshot(refs);
+	validate_snapshot(refs);
 
 	/*
 	 * Now make sure that the packed-refs file as it exists in the