On Mon, Dec 7, 2020 at 2:28 AM Ganriel Nützi <gnuetzi@xxxxxxxxx> wrote: > As of your rational, wouldn‘t it be good anyway to have a file > „worktree“ inside the .git dir (of the worktree) containing the path > to the main worktree? So to speak any worktree always has a .git dir > with a back link to its main worktree (the existence of the git dir > might pose other problems?) I'm having trouble understanding your proposal. Secondary worktrees don't have a .git/ directory; instead they have a "gitfile" named .git which is just a pointer to the worktree's administrative directory within the repository (specifically, <repo>/worktrees/<id>/, where <repo> might be a bare repository or the .git/ directory of the main worktree). So a secondary worktree's back-link is a pointer into the repository; it's not necessarily pointing at the main worktree, as you discovered and reported in the email which started this thread. What I was suggesting was that it might be the case that the only way to solve this would be to store the location of the main worktree somewhere within <repo> in some file, and then `git worktree list` would consult that file to learn the location of the main worktree. This is complicated by the fact that that file would have to be updated automatically if the main worktree directory is ever moved. It also needs to be done in such a way that it is easy for other Git implementations to understand and not trip over. So, it's certainly possible, but it's something which requires more thought, and there might be alternate and better solutions I'm overlooking.
