Tao Klerks <tao@xxxxxxxxxx> writes: > On Wed, Sep 6, 2023 at 10:26 PM Junio C Hamano <gitster@xxxxxxxxx> wrote: >> >> Tao Klerks <tao@xxxxxxxxxx> writes: >> >> > I like the nomenclature, I like the simple "zero (i.e. bare) or one >> > inline worktree, zero or more attached worktrees" explanation. >> >> We have used "main worktree" to refer to the working tree part (plus >> the repository) of a non-bare repository. And it makes sense to >> explain it together with the concept of "worktree", as the primary >> one is very much special in that it cannot be removed. You can see >> that "git worktree remove" would stop you from removing it with an >> error message: >> >> fatal: '../there' is a main working tree. >> >> It probably does not add much value to introduce a new term >> "inline". Here is what "git worktree --help" has to say about it. >> >> A repository has one main worktree (if it's not a bare repository) and >> zero or more linked worktrees. > > I've definitely changed my mind about "inline", I agree "main" is > better. I'm not convinced it's the best word we could come up with, > but if it's well-established, I'm happy with it. > > The problem I (now) see with "inline" is that it seems to imply a > spatial proximity that doesn't necessarily hold true, with > "--separate-git-dir" or other ways to separate the main worktree from > its usual "just above the .git directory" location. "Inline" is still > a reasonable qualification of the main worktree's *metadata* in that > situation (index, etc), but I think the word would not be sufficiently > clear/representative overall. It's not to argue in favor of "inline", just to clarify: I took it from inline-vs-attached as used in e-mail, where "inline" means that you see attachment right here, inline with the rest of text. I also admit I didn't happen to consider --separate-git-dir at the time.
