Re: [PATCH 2/9] remote: respect `core.defaultBranchName`
- From
Johannes Schindelin <johannes.schindelin@gmx.de>
- Date
- Jun 23, 2020, 21:15 UTC
- Message-ID
- <nycvar.QRO.7.76.6.2006232313540.54@tvgsbejvaqbjf.bet>
- In-Reply-To
- <20200618115028.GB41345@coredump.intra.peff.net>
Hi Peff,
On Thu, 18 Jun 2020, Jeff King wrote:
Show 25 quoted lines
> On Thu, Jun 18, 2020 at 12:21:30PM +0200, Johannes Schindelin wrote: > > > > 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`. > > I think we need to be a little careful with "any modern Git", because a > modern client against an old (or perhaps an alternative implementation) > server might still use it. I have to imagine it's pretty rare, but I > think it's still useful to return _some_ value. > > But as you note, even without a symref extension, we already try to > guess based on a unique branch. Probably even choosing the first one > alphabetically would be reasonable. But I'd rather err on the side of > historical compatibility if we can do so easily. Looking for > init.mainBranch, followed by master, accomplishes that and isn't many > lines of code.
I ended up using `init.defaultBranch` as preference, falling back to `master`, and then falling back to the first ref matching the given commit hash.
That should be safe enough.
Ciao, Dscho