Sorry, I missed this reply. On 24/9/24 04:52, Eric Sunshine wrote:
[1]: The discussion begins at the "Also Eric" paragraph of this email and continues in emails following it: https://lore.kernel.org/git/CACsJy8CXEKG+WNdSPOWF7JDzPXidSRWZZ5zkdMW3N3Dg8SGW_Q@xxxxxxxxxxxxxx/
Yes, Duh's comments pretty much sums it up.
This intuition perhaps arises from your background with "hg", but I have not formed any such intuition.
Not only from hg. You can freely move the parent directory of all CVS systems I'm aware of - hg, svn, cvs, rcs, sccs and yes git too. It only breaks when you add worktrees to git.
That's a very restrictive and limiting organization. As I understand it, one of the design goals of Git's linked worktrees was to allow worktrees to be placed anywhere, including on removable media or not-always-mounted network drives. (Yes, you may be able to do something similar with "hg" and symbolic links, but that doesn't play well with Windows users, at least not in the era when Git's worktree support was implemented.)
Yes, it is far more restrictive than git worktrees are now. It simplifies the users the mental model of what is going on, but that simplification comes at a cost. I only mentioned it because relative paths in worktrees would allow you to pretend it works that way.
Can you provide more details about this "mangling"? Although the use-case you describe was not directly considered in the initial design, worktrees hanging off a bare repository became an explicitly-supported use-case not long after worktrees were introduced. So, it should work properly and we know that people use worktrees this way, but we haven't had any reports of mangling in this scenario.
Phillip's reply was spot on: https://lore.kernel.org/git/87afa860-52f4-414a-82da-09e7eeac1301@xxxxxxxxx/
By the way, have you seen the patch recently posted[3] to explicitly support relative paths for worktrees? [3]: https://lore.kernel.org/git/pull.1783.git.git.1726880551891.gitgitgadget@xxxxxxxxx/
Ahh, now I see why using both is attractive
