From: Stefan Sperling Subject: Re: always fetch remote HEAD except when -b is used To: Christian Weisgerber Cc: gameoftrees@openbsd.org Date: Tue, 14 Feb 2023 16:48:56 +0100 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.