Caleb White <cdwhite3@xxxxx> writes:
> Changes in v5:
> - Added docs to `--relative-paths` option.
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).
> - Added test coverage for `repair_worktrees()` and relative paths.
> - Move `strbuf_reset` call in `infer_backlink()`.
This was more like "revert the change in v4 that moved it
unnecessarily", no?
> - Cleaned up tests.
Yup, there truely a lot of test changes between v4 and v5. Many
tests now use existing test helpers, which is good.
> - Slight stylistic changes.
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).
> - Tweaked commit messages.
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.
> - Updated base to 090d24e9af.
This made it harder than necessary to compare the two iterations, by
the way.
Thanks.
