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

Re: [PATCH 2/2] worktree: add `relativeWorktrees` extension

From
Taylor Blau <me@ttaylorr.com>
Date
Oct 28, 2024, 23:36 UTC
Message-ID
<ZyAgC1dRXIiLX9Vn@nand.local>
In-Reply-To
<D57O5LHGRN1M.WHYPYUEOUOFM@pm.me>
On Mon, Oct 28, 2024 at 07:00:11PM +0000, Caleb White wrote:
Show 8 quoted lines
> > But that's OK, and we can figure out a path forward here. I am just
> > trying to say that this highlights the importance of following the WC
> > reports regularly to catch cases where the maintainer missed some
> > important piece of information.
>
> My apologies, this was my first patch submission to Git and I was not
> exactly the process by which topics progressed from `seen` to `next` to
> `master`. I will be sure to follow the reports more closely in the future.

It's not a problem, and I am glad that you have found an interest in contributing to the Git project. We'll figure this one out :-).

Show 29 quoted lines
> >> Adding the extension was the direction suggested by Junio in the
> >> previous round. Git did not account for the possibility of the linking
> >> files containing relative paths, so there's really no way to make this
> >> change without breaking compatibility with older versions of Git. Git
> >> had to be taught how to handle files that could contain either absolute
> >> or relative paths.
> >
> > Yep, that makes sense. My preference here would be to make the new
> > behavior opt *in*, rather than opt-out, so that:
> >
> >   - Users who do not experience problems with writing worktrees that
> >     have absolute paths can continue to do so without any changes.
> >
> >   - Users who use worktrees *and* do not write relative paths can
> >     upgrade between successive versions without requiring a new
> >     repository extension that would break older Git versions.
> >
> >   - That we only add that extension to the repository's configuration if
> >     and when the user has opted into the new behavior.
> >
> > Reading this new series, I *think* that is the behavior that you settled
> > on, which seems quite reasonable to me. Can you confirm that I'm reading
> > this all correctly? Assuming so, I think that we are in a reasonable
> > position[^1] to review this series instead of having to back out the new
> > behavior.
>
> Yes this is correct. The new behavior is opt-in and the extension is
> only added to the repository configuration if the user creates
> a worktree with relative paths.

That is great. I'm glad that we're on the same page here, and that my understanding matches reality.

Show 6 quoted lines
> > Thanks for bearing with me here, I am quite embarrassed to have missed
> > Junio's mail that I mentioned earlier, but I appreciate your patience
> > while we sort this out together.
>
> No worries! I appreciate your feedback and I'm glad we're able to
> sort this out.

Not a problem, and again, I very much appreciate your patience and willingness to work on this.

Thanks, Taylor

Previous: Caleb White
Message 14 of 14 in “Allow relative worktree linking to be configured by the user”
  1. 0/2 Allow relative worktree linking to be configured by the userCaleb White, Oct 25, 2024
  2. 1/2 worktree: add CLI/config options for relative path linkingCaleb White, Oct 25, 2024
  3. Taylor BlauOct 28, 2024
  4. Taylor BlauOct 28, 2024
  5. Caleb WhiteOct 28, 2024
  6. Taylor BlauOct 28, 2024
  7. Caleb WhiteOct 28, 2024
  8. Caleb WhiteOct 28, 2024
  9. 2/2 worktree: add `relativeWorktrees` extensionCaleb White, Oct 25, 2024
  10. Taylor BlauOct 28, 2024
  11. Caleb WhiteOct 28, 2024
  12. Taylor BlauOct 28, 2024
  13. Caleb WhiteOct 28, 2024
  14. Taylor BlauOct 28, 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.