git/list[1] front-page[2] threads[3] people[4] search[5] about
 

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
Previous: Junio C Hamano
Message 7 of 7 in “Re: [PATCH v2 00/21] Support multiple worktrees”
  1. Duy NguyenDec 19, 2013
  2. Junio C HamanoDec 20, 2013
  3. Duy NguyenDec 21, 2013
  4. Junio C HamanoDec 22, 2013
  5. Duy NguyenDec 22, 2013
  6. Junio C HamanoDec 26, 2013
  7. Duy NguyenDec 28, 2013

Read the whole thread, see it on lore, or plain text.

$ cat FOOTERMessages come from the public archive at lore.kernel.org/git, fetched every hour. The front page is chosen and written each morning by an AI editor and can be wrong; the threads themselves are the record. About and API. For agents: an MCP server at https://gitlist.dev/mcp, and any thread, story or person page as Markdown by adding .md to its URL (or sending Accept: text/markdown). Details in /llms.txt.