On Tue, Sep 5, 2023 at 5:13 PM Junio C Hamano <gitster@xxxxxxxxx> wrote: > > Eric Sunshine <sunshine@xxxxxxxxxxxxxx> writes: > > >> All correct. The per-worktree part of the repository data does live > >> in a subdirectory of the ".git" directory and that was probably what > >> Tao had in mind, though. > > > > That could be. I read Tao's explanation as meaning that people do this: > > > > git clone foo.git foo > > cd foo > > git worktree add bar > > git worktree add baz > > > > rather than (perhaps) this: > > > > git clone foo.git foo > > cd foo > > git worktree add ../bar > > git worktree add ../baz > > Ah, that reading does totally make sense. > Fwiw, Eric's reading was my intended one. The people I have spoken with, as well as myself, have started using "git worktree" by doing the former, and only later felt really transgressive when placing the worktrees explicitly on a higher level, on equal footing with the "main worktree". To me it seemed natural that the "nested worktrees" approach was the expected one, as otherwise it gets even harder to explain/justify the operational difference between the "main worktree" and the other worktrees - then leading to the bare+worktrees approach to eliminate that operational difference. > But I am not sure it would lead to "we need to carefully protect the > primary worktree", because it is rather obvious, especially if you > bypass "git worktree remove" and use "rm -fr", you would lose > everybody underneath if you remove the "foo" in the "worktrees are > subdirectories of the primary" variant in the above examples. Right, sorry, too many poorly-expressed thoughts crammed together. We need to start carefully protecting main worktree *when we start to get clever* and actually add the worktrees as siblings to the main worktree. That protection is indeed "implicit" before you start using "../"... but then you have other issues of git-worktree-within-git-worktree confusion. Is there a manual for "expected typical usage of git worktree" somewhere? > > Even though deriving the worktree(s) from a separate and protected > bare repositories does protect you from total disaster caused by > removing "rm -fr" and bypassing "git worktree remove", it still > should be discouraged, as the per-worktree states left behind in the > repository interfere with the operations in surviving worktrees. Right, that's fine. Of course you're going to encourage deleting the worktrees carefully... but equally of-course, some people *will* do "rm -fr that-worktree-I-dont-know-how-to-clean", and when they do, telling them "just 'git worktree repair'" is much easier than telling them to "recover deleted files 'cause your local branches just evaporated" > Teaching folks not to do "rm -fr" would be the first step to a more > pleasant end-user experience, I would think. The less arcane trivia you *need* to teach users for them to be effective, the better the experience is for everyone. The fact that "deleting a standalone git repo only deletes what's in that standalone git repo the way you've done your whole life, but in this environment what look like multiple repos are actually 'worktrees', if you ever delete one your life *might*, if you choose the wrong one, suddenly be very unpleasant" is arcane trivia, in my opinion. Better to set things up so they *can't* shoot themselves in the foot with a bullet of that caliber.
