Re: [PATCH v5 5/5] worktree: copy sparse-checkout patterns and config on add

On Mon, Jan 31, 2022 at 10:01 AM Derrick Stolee via GitGitGadget
[off-list ref] wrote:

I think this is too fragile and may easily be broken by an unrelated
change since `realpath` is a temporary container which gets reused,
thus it holds different paths at different times. For instance, it
first holds the realpath of $GIT_DIR but then later holds the realpath
of $GIT_COMMON_DIR. If someone later comes along and reuses it for
some other path, then the code added by this patch may end up
breaking. To make this robust, you should instead use `sb_repo` which
already has the value "$GIT_DIR/worktrees/<name>":

    char *to_file = xstrfmt(%s/info/sparse-checkout", sb_repo.buf);

+               if (file_exists(from_file)) {
+                       if (safe_create_leading_directories(to_file) ||
+                           copy_file(to_file, from_file, 0666))
+                               error(_("failed to copy '%s' to '%s'; sparse-checkout may not work correctly"),
+                                     from_file, to_file);
+               }
+
+               free(from_file);
+               free(to_file);
+       }
+
+       /*
+        * If we are using worktree config, then copy all current config
+        * values from the current worktree into the new one, that way the
+        * new worktree behaves the same as this one.
+        */

As an aid for future readers, it might be helpful to extend this
content to explain _why_ the new worktree should behave the same as
the current one. Reproducing the important bits from the commit
message here in the comment could make it more useful.

+       if (repository_format_worktree_config) {
+               char *from_file = git_pathdup("config.worktree");
+               char *to_file = xstrfmt("%s/worktrees/%s/config.worktree",
+                                       realpath.buf, name);

Same comment about fragility of using `realpath`. Instead:

    char *to_file = xstrfmt("%s/config.worktree", sb_repo.buf);

+               if (file_exists(from_file)) {
+                       struct config_set cs = { { 0 }};

s/}}/} }/

+                       const char *str_value;
+                       int bool_value;
+
+                       if (safe_create_leading_directories(to_file) ||
+                           copy_file(to_file, from_file, 0666))
+                               die(_("failed to copy worktree config from '%s' to '%s'"),
+                                   from_file, to_file);

All the other error conditions handled by this patch use error() but
this one uses die(). Does this one really warrant aborting the `git
worktree add` operation? Perhaps instead just add a label below this
new chunk of code and `goto` the label (or indent this code further
and avoid adding a label).

+                       git_configset_init(&cs);
+                       git_configset_add_file(&cs, from_file);
+
+                       if (!git_configset_get_bool(&cs, "core.bare", &bool_value) &&
+                           bool_value &&

Nit: This would be slightly easier to understand if you named this
variable `bare` (as you did in patch [2/5]) rather than `bool_value`.

+                           git_config_set_multivar_in_file_gently(
+                                       to_file, "core.bare", NULL, "true", 0))
+                               error(_("failed to unset 'core.bare' in '%s'"), to_file);
+                       if (!git_configset_get_value(&cs, "core.worktree", &str_value) &&

In patch [2/5] you used git_configset_get_string_tmp() to retrieve
this setting, but here you're using git_configset_get_value(). Is
there a reason for the inconsistency?

For robustness, this should be using:

    new=$(git rev-parse --git-path info/sparse-checkout)

to retrieve ".git/worktrees/<id>/info/sparse-checkout" rather than
hard-coding "worktree" for "<id>".

Is this some debugging code you forgot to remove or was `git status`
failing due to the bug(s) fixed by this patch series? I'm guessing the
latter since you also use `git status` in more tests below. Anyhow,
it's not very clear what the `git-status` is meant to be testing. An
in-code comment _might_ help. Even better, perhaps, would be to add a
new single-purpose test or a well-named function which explicitly
checks the conditions you want to test (i.e. that git-config doesn't
report core.bare as true or core.worktree as having a value).

+       cat >expect <<-EOF &&
+       init.t
+       EOF
+       ls there3 >actual &&
+       test_cmp expect actual
+'
+
+test_expect_success '"add" to bare repo with worktree config' '
+       (
+               git clone --bare . bare3 &&
+               cd bare3 &&
+               git config extensions.worktreeconfig true &&
+               git config --worktree core.bare true &&
+               git config --worktree core.worktree "$(pwd)" &&

It's not clear to the casual reader why these nonsensical keys are
being added. An in-code comment explaining the reason (i.e. you expect
the `git worktree add` operation to drop them in the new worktree)
would be beneficial for future readers.

+               git config --worktree bogus.key value &&
+               git config --unset core.bare &&

Why is this being unset? (Genuine question. Am I missing something obvious?)

+               git worktree add ../there4 main &&
+               cd ../there4 &&
+               git status &&
+               git worktree add --detach ../there5 &&
+               cd ../there5 &&
+               git status
+       ) &&

Same comment about the purpose of git-status not being obvious. A
well-named function which checks the specific conditions you're
looking for would be more clear than abstruse invocations of
git-status.

+       # the worktree has the arbitrary value copied.
+       test_cmp_config -C there4 value bogus.key &&
+       test_cmp_config -C there5 value bogus.key &&
+
+       # however, core.bare and core.worktree were removed.
+       test_must_fail git -C there4 config core.bare &&
+       test_must_fail git -C there4 config core.worktree &&

This is the comment I was looking for above. It's certainly okay to
have it here, but it was confusing above to not understand the reason
those nonsensical keys were being added.

+       cat >expect <<-EOF &&
+       init.t
+       EOF
+
+       ls there4 >actual &&
+       test_cmp expect actual &&
+       ls there5 >actual &&
+       test_cmp expect actual
 '