On Wed, Feb 15, 2023 at 02:35:49AM +1100, Mark Jamsek wrote:
> That is, only fallback to fetching the remote's HEAD if there are no
> branches set in got.conf and there is no branch to be inferred from
> a work tree, or said branches don't exist on the server. And if -b is
> passed, we don't fallback to HEAD at all.

There was also the idea of 'got fetch' never adding HEAD to the list
of branches to fetch. We would then only use the remote HEAD as a
default when creating a fresh clone.

got-fetch-pack was first implenented for 'got clone', and when the fetch
command was added it inherted the HEAD fallback semantics of 'got clone'.
This was probably a mistake.

> I don't feel strongly either way so am more than happy to keep tweaking
> this till we get it right.

See my suggestions I wrote in response to naddy, and some more considerations
below.

HEAD is special for two reasons:
1) HEAD is a symbolic reference. We should probably define semantics for
fetching symrefs as opposed to fetching regular refs, and add specific
test cases.

2) HEAD is the only symref which the server announces when a client opens a
new session for fetching. Maybe it would be best to only act upon server-side
changes to HEAD by default, and leave other symrefs as-is unless they are
fetched explicitly.

If refs/remotes/foo/HEAD exists then it was fetched previously along with the
branch it points to. So HEAD should always point to a branch that exits in
refs/remotes as a regular reference.

In any case, when someone runs got fetch -bHEAD or adds a line like
branches { "HEAD" } to got.conf then we should probably be fetching it?

I suspect all this requires too much work for getting it done quickly,
and there is no reason to rush things.
To get the gotd segfault fix released, I propose that for now we revert
commit 2a19e2e21a876bbc4ae1999ca08ce4c8f2002158, cut a release, and then
bring this commit back and/or new work based on refined ideas.