On Thu, Sep 19, 2024 at 7:40 AM Russell Stuart <russell+git.vger.kernel.org@xxxxxxxxxxxx> wrote: > On 19/9/24 20:47, Eric Sunshine wrote: > > The idea of relative paths has been discussed previously[*] but was > > never implemented; although they may help some cases, they break > > other cases or at least make the other cases more difficult. For > > instance, relative paths only help if the main and linked worktrees > > move together in some uniform fashion, but don't help if they move in > > distinct ways. > > If breaking when moved is the criteria, then absolute paths always > break. Relative paths break slightly less often. So it seems to me > relative paths are an improvement - but not a fix. Indeed, I don't think anyone has argued against relative paths outright, but only pointed out that absolute and relative paths each have their strengths with regards to making the repair process (whether automatic or not) more robust. It was for this reason that the previous discussion[1] eventually settled on the idea of storing both absolute and relative paths. [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/ > It's always possible to break something by moving the wrong thing. For > example moving the .git directory in a normal repository would create a > mess. Yet, unlike moving worktrees (most?) people do not attempt to > move the .git directory in illegal ways. They always copy/more copy the > entire repository. It's intuitively obvious if you keep the .git > directory in the same relative position, it will work. This intuition perhaps arises from your background with "hg", but I have not formed any such intuition. > So my uniformed guess on how to "fix" the problem of people > moving/copying worktrees is to make equally obvious they must remain in > the same relative position to the parent. One way to do that is to use > the same structure hg uses, which is the child worktrees must all be in > the one common parent directory, and the parent directory contains the > .git metadata. It then becomes self-evident you can only more/copy the > entire thing - not bits of it. 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.) > Interestingly, people (including me as it happens) start out by trying > to emulate the hg approach using a single parent directory to hold a > bare repository, and the child worktree directories. Then they discover > bare repositories mangle the remote links, and give up on the idea. 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. > In > my case I then tried moving/copying the worktrees as a group using "git > worktree repair" to fix the mess, which eventually lead to this email :) Moving should have worked, either using "git worktree move" or by using "git worktree repair" after moving them manually. The copy case was broken as you reported. By the way, I posted a fix[2]. [2]: https://lore.kernel.org/git/20240923075416.54289-1-ericsunshine@xxxxxxxxxxx/ > Others have published of hacks / tricks that try to solve problem in > other ways, eg: https://github.com/Kristian-Tan/git-worktree-relative Interesting reading. > None of them work very well. Going on what Google throws up, moving > worktrees remains a commonly felt pain point. I suspect that the best way forward is to store both absolute and relative paths, but this needs to be done with care so as to not break existing tooling or other implementations of Git or Git libraries (including older versions of Git itself). 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/
