git/list[1] front-page[2] threads[3] people[4] search[5] about
 

Re: [PATCH v2 2/5] worktree: add `write_worktree_linking_files` function

From
Taylor Blau <me@ttaylorr.com>
Date
Oct 29, 2024, 22:55 UTC
Message-ID
<ZyFn9xErajxzQo29@nand.local>
In-Reply-To
<4a316a5f-9360-4f24-843f-bcbb5b3378c4@gmail.com>
On Tue, Oct 29, 2024 at 02:52:36PM +0000, Phillip Wood wrote:
Show 13 quoted lines
> Hi Caleb
>
> On 28/10/2024 19:09, Caleb White wrote:
> > A new helper function, `write_worktree_linking_files()`, centralizes
> > the logic for computing and writing either relative or absolute
> > paths, based on the provided configuration. This function accepts
> > `strbuf` pointers to both the worktree’s `.git` link and the
> > repository’s `gitdir`, and then writes the appropriate path to each.
>
> That sounds like a useful change. I think it would be better to pass an
> extra parameter "use_relative_paths" rather than relying on a global
> varibale in worktree.c. Thank you for adding some documentaion for the new
> function.
Good suggestion. I definitely agree that this is a useful direction.
Show 7 quoted lines
> > This also teachs `git worktree repair` to fix the linking files if
> > there is an absolute/relative paths but the links are correct. E.g.,
> > `git worktree repair` can be used to convert a valid worktree between
> > absolute and relative paths.
>
> This might be better as a separate step so that reviewers can concentrate on
> the correctness of write_werktree_linking_files() when reviewing this patch.

Indeed. This patch (even though the diffstat isn't overly large) is somewhat noisy just because of the number of spots that needed to be adjusted here.

I wonder if another way to split this up (in addition to what you wrote above) might be to introduce the new function and convert one single caller in the first patch. Then subsequent patches can go one callsite at a time and convert them to use the new function.

That way, each patch is easy-ish to verify in isolation. I know that results in some more patches, but I think that the additional clarity I imagine we'll get is worth doing so.

Thanks, Taylor

Previous: Phillip WoodNext: Caleb White
Message 13 of 26 in “Allow relative worktree linking to be configured by the user”
  1. 0/5 Allow relative worktree linking to be configured by the userCaleb White, Oct 28, 2024
  2. 1/5 worktree: add CLI/config options for relative path linkingCaleb White, Oct 28, 2024
  3. Phillip WoodOct 29, 2024
  4. Caleb WhiteOct 30, 2024
  5. Taylor BlauOct 30, 2024
  6. Caleb WhiteOct 30, 2024
  7. phillip.wood123@gmail.comOct 30, 2024
  8. Caleb WhiteOct 30, 2024
  9. Taylor BlauOct 29, 2024
  10. Caleb WhiteOct 30, 2024
  11. 2/5 worktree: add `write_worktree_linking_files` functionCaleb White, Oct 28, 2024
  12. Phillip WoodOct 29, 2024
  13. Taylor BlauOct 29, 2024
  14. Caleb WhiteOct 30, 2024
  15. Caleb WhiteOct 30, 2024
  16. 3/5 worktree: add tests for worktrees with relative pathsCaleb White, Oct 28, 2024
  17. Phillip WoodOct 29, 2024
  18. Caleb WhiteOct 29, 2024
  19. phillip.wood123@gmail.comOct 29, 2024
  20. Caleb WhiteOct 30, 2024
  21. Taylor BlauOct 29, 2024
  22. Caleb WhiteOct 30, 2024
  23. 4/5 setup: correctly reinitialize repository versionCaleb White, Oct 28, 2024
  24. 5/5 worktree: add `relativeWorktrees` extensionCaleb White, Oct 28, 2024
  25. Phillip WoodOct 29, 2024
  26. Caleb WhiteOct 30, 2024

Read the whole thread, see it on lore, or plain text.

$ cat FOOTERMessages come from the public archive at lore.kernel.org/git, fetched every hour. The front page is chosen and written each morning by an AI editor and can be wrong; the threads themselves are the record. About and API. For agents: an MCP server at https://gitlist.dev/mcp, and any thread, story or person page as Markdown by adding .md to its URL (or sending Accept: text/markdown). Details in /llms.txt.