Re: [PATCH v2 00/21] Support multiple worktrees
- From
Duy Nguyen <pclouds@gmail.com>
- Date
- Dec 28, 2013, 02:46 UTC
- Message-ID
- <CACsJy8BV39frnQo1BW2p1J7H0pU7LifzcUey61J5Jkc6Wn=2rw@mail.gmail.com>
- In-Reply-To
- <7vy537k038.fsf@alter.siamese.dyndns.org>
On Fri, Dec 27, 2013 at 12:12 AM, Junio C Hamano <gitster@pobox.com> wrote:
Show 30 quoted lines
> Duy Nguyen <pclouds@gmail.com> writes: > >> On Sun, Dec 22, 2013 at 1:38 PM, Junio C Hamano <gitster@pobox.com> wrote: >> >>> Do we even need to expose them as ref-like things as a part of the >>> external API/UI in the first place? For end-user scripts that want >>> to operate in a real or borrowing worktree, there should be no >>> reason to touch this "other" repository directly. Things like "if >>> one of the wortrees tries to check out a branch that is already >>> checked out elsewhere, error out" policy may need to consult the >>> other worktrees via $GIT_COMMON_DIR mechanism but at that level we >>> have all the control without contaminating end-user facing ref >>> namespace in a way main/FETCH_HEAD... do. >> >> No, external API/UI is just extra bonus. We need to (or should) do so >> in order to handle $GIT_COMMON_DIR/HEAD exactly like how we do normal >> refs. > > And that is what I consider a confusion-trigger, not a nice bonus. > > I do not think it is particularly a good idea to contaminate > end-user namespace for this kind of "peek another repository" > special operation. > > In order to handle your "multiple worktrees manipulating the same > branch" case sanely, you need to be aware of not just the real > repository your worktree is borrowing from, but also _all_ the other > worktrees that borrow from that same real repository, so a single > "main" virtual namespace will not cut it. You will be dealing with > an unbounded set of HEADs, one for each such worktree.
Yes. My problem is, while all secondary worktrees are in $GIT_DIR/repos and their HEADs can be accessed there with "repos/xxx/HEAD", the first worktree's HEAD can't be accessed this way because "HEAD" in a linked checkouts means repos/<my worktree>/HEAD.
> Can't we do this by adding a "with this real repository" layer, > e.g. "resolve HEAD wrt that repository", somewhat similar to how we > peek into submodule namespaces?
Hmm.. never thought of it like a "submodule". Thanks for the idea.
-- Duy