On 23-02-14 04:48PM, Stefan Sperling wrote:
> 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.
> > > 
> > I'm struggling to make sense of the semantics here.
> > 
> > ...
> > 
> > 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.

I really like the sound of your first proposed solution! Like you, I'm
not a fan of the second. The third would be my runners-up pick; it's not
unreasonable to assume users will have enough information to learn when
HEAD changes and act accordingly, and doesn't have the DWIM smell like
the current behaviour and option 1 arguably does.

If naddy thinks solution 1 sounds good, too, I can do this tomorrow
after work if you like.

-- 
Mark Jamsek <fnc.bsdbox.org|got.bsdbox.org>
GPG: F2FF 13DE 6A06 C471 CA80  E6E2 2930 DC66 86EE CF68