Re: [PATCH v5 0/8] Allow relative worktree linking to be configured by the user

Caleb White <cdwhite3@pm.me> writes:

You already had doc on this, but the default was not described at all.

 --[no-]relative-paths::
+       Link worktrees using relative paths or absolute paths (default).

This was more like "revert the change in v4 that moved it unnecessarily", no?

Yup, there truely a lot of test changes between v4 and v5. Many tests now use existing test helpers, which is good.

I saw many changes like these (the diff is between v4 and v5)

 static void repair_gitfile(struct worktree *wt,
-                          worktree_repair_fn fn,
-                          void *cb_data,
+                          worktree_repair_fn fn, void *cb_data,
                           int use_relative_paths)

which looked good (the original had fn and cb_data defined on the same line).

Updates to the proposed log message for `repair` step [7/8] did not really "clarify", other than helping readers to see how messy things are. It said:

    +    To simplify things, both linking files are written when one of the files
    +    needs to be repaired. In some cases, this fixes the other file before it
    +    is checked, in other cases this results in a correct file being written
    +    with the same contents.

which may describe what the code happens to do correctly, but does not quite help building the confidence in what it does is correct.

Suppose that the directory X has a repository, and the repository thinks that the directory W is its worktree. But the worktree at the directory W thinks that its repository is not X but Y, and there indeed is a repository at the directory Y. That repository thinks W belongs to it.

If we examine X first, would we end up updating W to point at X (because X thinks W is its worktree)?

Or do we make W to point at Y (because Y thinks W is its, and W thinks it is Y's)"?

Either way, I think the comment is trying to say that, if we decide to make X and W belong to each other, we'd overwrite links from X to W and also W to X, even though the link from X was already pointing at W and the minimum fix we needed to make was to update the link from W to point at X. Overwriting a link from X to W with a new link from X to W is a no-op, so it does not seem to help greatly, since `repair` is not at all performance critical. The correctness is a lot more important.

This made it harder than necessary to compare the two iterations, by the way.

Thanks.