Re: [PATCH 00/12] Fix various overly aggressive protections in 2.45.1 and friends

[Junio C Hamano <gitster@pobox.com>]

Junio C Hamano <gitster@pobox.com> writes:

> Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
>
>> On Tue, 21 May 2024, Junio C Hamano wrote:
>>
>>> I'll figure out a way to convey conflict resolutions as this topic
>>> gets merged up to newer maintenance tracks on the list so that
>>> people can assist with ensuring correctness of the result by
>>> reviewing, and follow up. ("git show --remerge-diff" might turn out
>>> to be such a way, but I do not know yet).
>>
>> I pushed 12/12 to https://github.com/dscho/git's
>> `various-fixes-for-v2.45.1-and-friends` branch, and updated the
>> `tentative/maint-*` branches accordingly:
>
> Thanks, but I suspect it is not productive use of your time to merge
> these up until we know we are happy with what we are merging up.
>
> Even though I did the 12/12 that reverts the "iffy ownership check
> during repository discovery", it is far from clear without
> discussion if that is a reasonable thing to do or use of
> safe.directory by narrow non-target audience (like k.org that may
> use gitolite and/or bare git for hosting) that lets nobody access
> trusted user repositories.  Every time we find new issues or
> different solutions, somebody has to merge it up, eventually to
> maint-2.45, but I am afraid it may be a bit too early to commit.

Another thing is that, now this is not an embargoed set of secret
releases, I'd want to have them go through 'next' down to 'master'
in the usual way, with the usual "develop in the open" fashion,
before we convince ourselves that the whole cascade is ready.  We
may find necessary updates while these fixes are in 'next' due to
$WORK folks feeding 'next' based updates to $CORP users and helping
us find issues, in which case we would need to add more patches on
top of the topic based on maint-2.39 (and merge it up all the way).
After that is all done, we would finally become ready to write
release notes for the tracks, which will be merged up the same way
as the "oops, we found we need another patch while the series was in
'next'" case.  Preparing tentative/maint-* set of branches your way,
with release notes and GIT-VERSION-GEN updates together ready to be
tagged, would not help prepare something that I can feed other
developers in 'seen' and then 'next'.

Thanks.