Re: [PATCH] glossary: describe "worktree"

Ævar Arnfjörð Bjarmason <avarab@gmail.com> writes:

Not only FETCH_HEAD is a multi-line file, but each entry in it carry extra information that do not belong to a 'ref', like where it came from and whether its intended use is to merge into the current branch.

The file is much closer to what "rebase -i" uses its "todo list" for, than being a "ref-like" thing. The only similarity with a loose ref is that it begins with 40-hex and get_sha1_hex() will happily return success. The file format was designed to take advantage of the loose-ness of get_sha1_hex(), historically, so that the reading side can reuse the logic to read loose refs.

You can blame all of that to my laziness ;-).

After you fetch a single ref, get_oid("FETCH_HEAD") should keep returning the object name of what you fetched, but that does not mean the full multi-line trash needs to be stored in any ref backend. If you fetch multiple refs, get_oid("FETCH_HEAD") can only return one of them anyway, so as long as we keep the only useful use case working, we do not have to use the machinery the ref backend of choice uses to store it. It can remain an on-disk file, just like the "todo" list "rebase -i" uses is an on-disk file.