Re: a less-invasive racy-leak fix, was Re: What's cooking in git.git (Dec 2024, #11; Mon, 30)

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

Jeff King <peff@peff.net> writes:

> On Wed, Jan 01, 2025 at 04:25:02PM -0800, Junio C Hamano wrote:
>
>> Jeff King <peff@peff.net> writes:
>> 
>> > On Mon, Dec 30, 2024 at 09:33:20AM -0800, Junio C Hamano wrote:
>> >
>> >> * jk/lsan-race-with-barrier (2024-12-30) 5 commits
>> > ...
>> > This graduated faster than I expected. :)
>> 
>> Heh, it is before -rc2 and the change is only about tests, so ...
>
> Yeah, I figured as much. I also considered it of relatively low
> importance during -rc, but I guess CI false positives do tend to annoy
> everybody and waste their time. :)
>
> It looks like you pushed out the version of 'master' with it merged. I
> had figured you'd revert jk/lsan-race-with-barrier out of next, so I
> wondered how we would proceed (revert the whole merge from master to
> rebuild, or do a moral revert of the final three).

Revert the effect of the tip-part (except for the bottom two) and
then queue the new ones, which would allow me to merge the whole
thing in one go without losing the bottom two's effect (which would
happen if we reverted the whole thing first, and then reused the
bottom two commits to build the new iteration on top).

> Looking at jk/lsan-race-ignore-false-positive, it looks like you did the
> moral revert via fc89d14c63 (Revert barrier-based LSan threading race
> workaround, 2025-01-01). That commit's tree matches what I'd expect (I
> guess you probably used "revert -n HEAD~3..HEAD" just like I did).

I actually did "read-tree -u -m" followed by "commit" ;-) 

> It would be nice if the 3-commit revert mentioned the specific commits
> it was reverting.

True.  I should probably amend while I can.

> I wonder if revert should have a "squash" mode that reverts all of the
> commits (perhaps in reverse order of application in case they depend on
> each other textually), and then gives you a commit message template
> similar to git-fmt-merge-msg, where we list all of the commits, one per
> line (though probably with their commit ids in this case).

I am not sure if I follow.  Should "revert HEAD~3..HEAD" give such
concatenation of messages, something similar to what "rebase -i"
gives us when seeing multiple "squash"es in a row?