On Tue, Feb 14, 2023 at 04:17:09PM +0100, Christian Weisgerber wrote:
> Mark Jamsek:
> 
> > As discussed with stsp on irc, this tweaks 'got fetch' again so that the
> > branch resolved via the remote's HEAD ref is not just a fallback--it is
> > always fetched except in the 'got fetch -b branch' case.
> > 
> > This necessitated passing the bflag to got_fetch_pack from cmd_clone(),
> > too, so that we don't fetch HEAD when 'got clone -b branch' is used.
> 
> I'm struggling to make sense of the semantics here.
> 
> $ got clone -b stable/13 ssh://anongit@git.freebsd.org/src.git
> ...
> $ cd src.git
> $ got ref -l | fgrep -v /tags/
> HEAD: refs/heads/stable/13
> refs/heads/stable/13: acaed6b1e2859cb6726e35e8c937b192c16a95c8
> refs/remotes/origin/stable/13: acaed6b1e2859cb6726e35e8c937b192c16a95c8
> $ got fetch
> ...
> $ got ref -l | fgrep -v /tags/
> HEAD: refs/heads/stable/13
> refs/heads/main: 825fbd087e6150eaf601612a5e7468ddc808e004
> refs/heads/stable/13: acaed6b1e2859cb6726e35e8c937b192c16a95c8
> refs/remotes/origin/HEAD: refs/remotes/origin/main
> refs/remotes/origin/main: 825fbd087e6150eaf601612a5e7468ddc808e004
> refs/remotes/origin/stable/13: acaed6b1e2859cb6726e35e8c937b192c16a95c8
> 
> Presumably, if I limit "clone" to a particular branch, that's all
> I'm interested in, and I don't expect the next "fetch" to add the
> remote HEAD branch.

Fetching HEAD by default prevents people from potentially working
on a stale main branch, e.g. when a project switches to a different
main branch and updates HEAD accordingly.
This can happen for various reasons, such as master -> main renames
which were common over the last few years. And in our own -portable
repository the main branch is still called "linux" for historical
reasons, which could change in the future.
Our assumption was that everything else will generally be close to or
derived from HEAD, and that fetching the extra data should not be a burden.

But you present a use case which I did not consider.
Presumably in this situation a stable-only clone will receive less changes
over time than HEAD does, so your repository now stores more commits than
actually needed (to fix it, remove the references you don't want and then
run 'git gc', potentially with an option like --prune=now).

Regarding got fetch behaviour, I see several ways forward:

We could fetch HEAD by default only if the symref refs/remotes/foo/HEAD
already exits, and if its target no longer matches the remote HEAD.
This would preserve the behaviour you want for -stable repositories
while also satisfying the above concern.

We could provide a got.conf flag to control this behaviour (I'd rather not):
  fetch-head-by-default yes|no

Revert back to the previous behaviour, with the downside that changes to
HEAD must be learned and followed manually.