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

Re: [PATCH] glossary: describe "worktree"

From
Han-Wen Nienhuys <hanwen@google.com>
Date
Feb 17, 2022, 10:00 UTC
Message-ID
<CAFQ2z_O=WguSAJDD4DRpwtX54A5dWQZQPCuQDR81idknQgchaA@mail.gmail.com>
In-Reply-To
<xmqqczjuttyw.fsf@gitster.g>
On Thu, Feb 10, 2022 at 8:14 PM Junio C Hamano <gitster@pobox.com> wrote:
Show 14 quoted lines
>
> Han-Wen Nienhuys <hanwen@google.com> writes:
>
> > on a tangent: I posted a patch to write MERGE_AUTOSTASH,
> > rebase-merge/autostash, etc. as refs.
> > Is that the right direction? They are read like refs, but they are
> > together in a directory with other bits of stateful data (similar to
> > what is appended to FETCH_HEAD). Perhaps I should rather change the
> > read path, so they're always read as files rather than refs?
>
> I think that would be a lot more preferrable.  If a file is written
> to record pieces of info, among which an object name happens to be
> included, it does not have to be recorded as a ref.  Especially if
> it is an ephemeral file like MERGE_AUTOSTASH and FETCH_HEAD.
For FETCH_HEAD, doing
  git fetch host refs/changes/23/123/1 && git checkout FETCH_HEAD

is the standard idiom for downloading a change from Gerrit. I suspect there might be other similar idioms. This means we have to read them through the refs machinery.

I think the most sensible approach is to pass the read/write through refs_* functions, but special-case the storage, so it doesn't go through reftable. We already do this for FETCH_HEAD and MERGE_HEAD in refs_read_raw_refs.

This means we need a formal definition of which refs should be treated as files. Maybe we could do as follows:

Pseudorefs are
  1) all uppercase toplevel names except for HEAD
  2) all refs that are not under refs/* (for example:
rebase-{merge,apply}/autostash)
Pseudorefs are always stored as files containing a hex object_id.

Pseudorefs can be read or written through refs_* functions, but given the storage guarantees, it's also valid to read/write them outside refs_* functions

It is forbidden to make cross-ref transactions that involve pseudorefs.
-- 
Han-Wen Nienhuys - Google Munich
I work 80%. Don't expect answers from me on Fridays.
--
Google Germany GmbH, Erika-Mann-Strasse 33, 80636 Munich
Registergericht und -nummer: Hamburg, HRB 86891
Sitz der Gesellschaft: Hamburg
Geschäftsführer: Paul Manicle, Liana Sebastian
Previous: Junio C HamanoNext: Junio C Hamano
Message 10 of 14 in “glossary: describe "worktree"”
  1. glossary: describe "worktree"Junio C Hamano, Feb 10, 2022
  2. Derrick StoleeFeb 10, 2022
  3. Elijah NewrenFeb 10, 2022
  4. Junio C HamanoFeb 10, 2022
  5. Elijah NewrenFeb 10, 2022
  6. Han-Wen NienhuysFeb 10, 2022
  7. Junio C HamanoFeb 10, 2022
  8. Han-Wen NienhuysFeb 10, 2022
  9. Junio C HamanoFeb 10, 2022
  10. Han-Wen NienhuysFeb 17, 2022
  11. Junio C HamanoFeb 17, 2022
  12. Ævar Arnfjörð BjarmasonFeb 18, 2022
  13. Junio C HamanoFeb 18, 2022
  14. Junio C HamanoFeb 10, 2022

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.