Hi Peff,
On Tue, 16 Jun 2020, Jeff King wrote:
> On Wed, Jun 10, 2020 at 09:19:23PM +0000, Johannes Schindelin via GitGitGadget wrote:
>
> > @@ -2099,7 +2100,10 @@ struct ref *guess_remote_head(const struct ref *head,
> >
> > /* If refs/heads/master could be right, it is. */
> > if (!all) {
> > - r = find_ref_by_name(refs, "refs/heads/master");
> > + char *name = git_default_branch_name(0);
> > +
> > + r = find_ref_by_name(refs, name);
> > + free(name);
> > if (r && oideq(&r->old_oid, &head->old_oid))
> > return copy_ref(r);
> > }
>
> You'd perhaps want to update the comment above, too.
>
> However, I think we should be a bit more lenient on the "reading" side
> default names. Just because "foo" is _my_ default branch name, does not
> mean it is the default on the remote side. We cannot know what the other
> side's default preference is, but in a world where we have 15 years of
> repos that may have been created with "master", it is probably still a
> good guess.
>
> I.e., I think this probably ought to check the preferred name, and then
> fall back to the existing behavior, like:
>
> if (!all) {
> char *name;
>
> /* try the user's preferred default branch name */
> name = git_default_branch_name(0);
> r = find_ref_by_name(refs, name);
> free(name);
> if (r && oideq(&r->old_oid, &head->old_oid))
> return copy_ref(r);
>
> /* otherwise, try "master", which is the historical default */
> r = find_ref_by_name(refs, "refs/heads/master");
> if (r && oideq(&r->old_oid, &head->old_oid))
> return copy_ref(r);
> }
>
> That will help minimize fallout when git_default_branch_name() changes,
> either by user config or if we switch the baked-in default. In the
> latter case, we might also consider hard-coding that as a guess between
> the user's preferred name and the historical "master".
>
> Hopefully this would not matter _too_ much either way, as most servers
> would support the symref extension these days. But I still think we
> should do our best to minimize spots where the user may see a
> regression.
Sure, we could just leave this alone, or we can just ditch the
special-casing of `master` here.
As you say, this does not affect any modern Git version, and IIRC the code
after that special-casing tries to find any remote ref that matches the
remote `HEAD`.
So it's not like we _need_ this special-casing, anyway.
Ciao,
Dscho
