tmp-objdir: fix regressions in core.fsyncobjectfiles=batch

* Fix prune code to be able to work against multiple cruft directories. I noticed this in self-review.

* When dscho enabled core.fsyncobjectfiles=batch in git-for-windows we saw some test-failures in update-index tests. The root cause is that setup_work_tree does a chdir_notify, which erases the tmp-objdir state. I now unapply and reapply the tmp-objdir around setup_git_env.

This branch autosquashes cleanly and it needs to be merged with ns/batched-fsync, where it currently merges cleanly.

Neeraj Singh (2):
fixup! tmp-objdir: new API for creating temporary writable databases fixup! tmp-objdir: new API for creating temporary writable databases

 builtin/prune.c |  1 +
 environment.c   |  5 +++++
 tmp-objdir.c    | 25 +++++++++++++++++++++++++
 tmp-objdir.h    | 15 +++++++++++++++
 4 files changed, 46 insertions(+)

base-commit: 50741b157f2f90df76a60418e2781b2c1e6e3c78
Published-As: https://github.com/gitgitgadget/git/releases/tag/pr-1067%2Fneerajsi-msft%2Fns%2Ftmp-objdir-fixes-v1
Fetch-It-Via: git fetch https://github.com/gitgitgadget/git pr-1067/neerajsi-msft/ns/tmp-objdir-fixes-v1
Pull-Request: https://github.com/gitgitgadget/git/pull/1067

gitgitgadget

From: Neeraj Singh <[email protected]>

Fix prune code to be able to delete multiple object directories. I wasn't properly resetting the strbuf with the path.

---
 builtin/prune.c | 1 +
 1 file changed, 1 insertion(+)

index 9c72ecf5a58..6b6b0c7b011 100644
@@ -31,6 +31,7 @@ static int prune_tmp_file(const char *fullpath)
 		if (show_only || verbose)
 			printf("Removing stale temporary directory %s\n", fullpath);
 		if (!show_only) {
+			strbuf_reset(&remove_dir_buf);
 			strbuf_addstr(&remove_dir_buf, fullpath);
 			remove_dir_recursively(&remove_dir_buf, 0);
 		}

gitgitgadget

From: Neeraj Singh <[email protected]>

When setup_work_tree executes, it redoes setup of the object database path and various other aspects of the_repository. This destroys the temporary object database state.

This commit removes the temporary object database and reapplies it around the operations in the chdir_notify callback.

---
 environment.c |  5 +++++
 tmp-objdir.c  | 25 +++++++++++++++++++++++++
 tmp-objdir.h  | 15 +++++++++++++++
 3 files changed, 45 insertions(+)

index 46ec5072c05..7ba5ae06c71 100644
@@ -17,6 +17,7 @@
 #include "commit.h"
 #include "strvec.h"
 #include "object-store.h"
+#include "tmp-objdir.h"
 #include "chdir-notify.h"
 #include "shallow.h"
 

@@ -344,10 +345,14 @@ static void update_relative_gitdir(const char *name,
 				   void *data)
 {
 	char *path = reparent_relative_path(old_cwd, new_cwd, get_git_dir());
+	struct tmp_objdir *tmp_objdir = tmp_objdir_unapply_primary_odb();
 	trace_printf_key(&trace_setup_key,
 			 "setup: move $GIT_DIR to '%s'",
 			 path);
+
 	set_git_dir_1(path);
+	if (tmp_objdir)
+		tmp_objdir_reapply_primary_odb(tmp_objdir, old_cwd, new_cwd);
 	free(path);
 }
 

index 45d42a7bcf0..3d38eeab66b 100644
@@ -1,5 +1,6 @@
 #include "cache.h"
 #include "tmp-objdir.h"
+#include "chdir-notify.h"
 #include "dir.h"
 #include "sigchain.h"
 #include "string-list.h"

@@ -12,6 +13,7 @@ struct tmp_objdir {
 	struct strbuf path;
 	struct strvec env;
 	struct object_directory *prev_odb;
+	int will_destroy;
 };
 
 /*

@@ -315,4 +317,27 @@ void tmp_objdir_replace_primary_odb(struct tmp_objdir *t, int will_destroy)
 	if (t->prev_odb)
 		BUG("the primary object database is already replaced");
 	t->prev_odb = set_temporary_primary_odb(t->path.buf, will_destroy);
+	t->will_destroy = will_destroy;
+}
+
+struct tmp_objdir *tmp_objdir_unapply_primary_odb(void)
+{
+	if (!the_tmp_objdir || !the_tmp_objdir->prev_odb)
+		return NULL;
+
+	restore_primary_odb(the_tmp_objdir->prev_odb, the_tmp_objdir->path.buf);
+	the_tmp_objdir->prev_odb = NULL;
+	return the_tmp_objdir;
+}
+
+void tmp_objdir_reapply_primary_odb(struct tmp_objdir *t, const char *old_cwd,
+		const char *new_cwd)
+{
+	char *path;
+
+	path = reparent_relative_path(old_cwd, new_cwd, t->path.buf);
+	strbuf_reset(&t->path);
+	strbuf_addstr(&t->path, path);
+	free(path);
+	tmp_objdir_replace_primary_odb(t, t->will_destroy);
 }

index 75754cbfba6..a3145051f25 100644
@@ -59,4 +59,19 @@ void tmp_objdir_add_as_alternate(const struct tmp_objdir *);
  */
 void tmp_objdir_replace_primary_odb(struct tmp_objdir *, int will_destroy);
 
+/*
+ * If the primary object database was replaced by a temporary object directory,
+ * restore it to its original value while keeping the directory contents around.
+ * Returns NULL if the primary object database was not replaced.
+ */
+struct tmp_objdir *tmp_objdir_unapply_primary_odb(void);
+
+/*
+ * Reapplies the former primary temporary object database, after protentially
+ * changing its relative path.
+ */
+void tmp_objdir_reapply_primary_odb(struct tmp_objdir *, const char *old_cwd,
+		const char *new_cwd);
+
+
 #endif /* TMP_OBJDIR_H */

gitgitgadget

Hi Neeraj,

Thank you for the fast work on the fixes!

I applied both patches to the PR branch and pushed; Let's see how the CI over at https://github.com/git-for-windows/git/pull/3492 pans out.

Please note the original patch made it into next already (and is hence subject to follow-up patches rather than being rewritten).

Therefore, you may need to reword the commit messages so that they stand on their own, as follow-up commits.

And alternative would be to ask Junio to kick the topic out of next and back to seen, in which case you will probably be asked to submit a new iteration of the original patch.

Thank you again!
Dscho

Yeah, none of the above is attractive this late in the cycle X-<.

It probalby is best to queue the "fixup!" commits as they are on top of ns/tmp-objdir, merge the result to two topics that depend on ns/tmp-objdir, and keep them without merging them down, until the release. When it is time to rewind 'next' after the release, it would be a good chance to get rid of these "oops, earlier we screwed up" commits by redoing the tmp-objdir (and rebasing the other two topics on top).

Hi Junio,
Apologies for the breakage! I just want to be 100% clear here: is there any action I should take with the patches, or will you handle the merge/rebase?

FYI for anyone trying this on git-for-windows, there's one additional patch at:
https://github.com/neerajsi-msft/git/commit/435e1d2e5e8fb422b0f08ff6a01a130584f7e249

That fixes a gfw-specific breakage that affects tmp_objdir_migrate and causes it to infinitely create recursive directories until the disk fills up (surprisingly we don't hit stack overflow first).

Thanks,
Neeraj

If we all agree on the above plan, then nothing for you for now, but we'd ask you to send a cleaned-up patch after the upcoming release when the 'next' branch gets rewound and rebuilt, at which time we can get rid of the "oops, we screwed up" fixup patches.

Thanks for finding and sending in the fix.