Ævar Arnfjörð Bjarmason <avarab@xxxxxxxxx> writes:
> But I may be entirely missing the point here...
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.
