From: Junio C Hamano <gitster@pobox.com>
To: Patrick Steinhardt <ps@pks.im>
Cc: git@vger.kernel.org
Subject: Re: malloc: *** error for object 0x1: pointer being freed was not allocated on MacOS with git 2.47.0
Date: Tue, 19 Nov 2024 08:51:29 +0900 [thread overview]
Message-ID: <xmqqy11ghzi6.fsf@gitster.g> (raw)
In-Reply-To: <Zzs8JJO_HCLrEBM0@pks.im> (Patrick Steinhardt's message of "Mon, 18 Nov 2024 14:07:48 +0100")
Patrick Steinhardt <ps@pks.im> writes:
> On Mon, Nov 18, 2024 at 09:42:03PM +0900, Junio C Hamano wrote:
>> Patrick Steinhardt <ps@pks.im> writes:
>> > ps/upgrade-clar
>> > wm/shortlog-hash
>>
>> Unfortuately, these were both based not on 'maint' but on 'master',
>> and cannot ever be merged down to 'maint'. The last topic may
>> deserve to be cherry-picked to 'maint' when the time comes.
>
> We got several reports about build failures with clar on esoteric
> platforms, and ps/upgrade-clar fixes those. Distro maintainers can of
> course cherry-pick those patches, but I think it would make sense to
> pull them into a maintenance release.
>
> I am happy to provide a backport for ps/upgrade-clar if you agree with
> me.
I am primarily following the wish left by the interim maintainer.
If a fix was based on 'master', it was deemed not critical to be
downmerged to 'maint'. Other fixes may have been forked from
'maint'. Cherry-picking is a declaration that the initial choice
was a grave mistake, and I'd rather avoid that for a small thing
that are not critical to the end-users and only affects developers.
In addition, for those building themselves, I'd prefer to nudge them
to be on the latest release, and not backporting developer features
at fringe like testing is probably a sensible way to do so.
Cherry-picking I can handle myself if it is necessaary. Accepting a
new patch from you would cost me more time than that ;-).
Thanks.
next prev parent reply other threads:[~2024-11-18 23:51 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-11-15 9:40 malloc: *** error for object 0x1: pointer being freed was not allocated on MacOS with git 2.47.0 Attila Kerekes
2024-11-15 16:34 ` René Scharfe
2024-11-15 17:23 ` Junio C Hamano
2024-11-18 8:19 ` Patrick Steinhardt
2024-11-18 12:42 ` Junio C Hamano
2024-11-18 13:07 ` Patrick Steinhardt
2024-11-18 23:51 ` Junio C Hamano [this message]
2024-11-18 19:28 ` Philippe Blain
2024-11-19 0:33 ` Junio C Hamano
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=xmqqy11ghzi6.fsf@gitster.g \
--to=gitster@pobox.com \
--cc=git@vger.kernel.org \
--cc=ps@pks.im \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox