From: Junio C Hamano <gitster@pobox.com>
To: Jeff King <peff@peff.net>
Cc: git@vger.kernel.org
Subject: Re: What's cooking in git.git (Sep 2022, #02; Fri, 9)
Date: Sun, 11 Sep 2022 17:32:31 -0700 [thread overview]
Message-ID: <xmqqo7vlh1pc.fsf@gitster.g> (raw)
In-Reply-To: <Yx1tnBRXJdkFQYEX@coredump.intra.peff.net> (Jeff King's message of "Sun, 11 Sep 2022 01:09:48 -0400")
Jeff King <peff@peff.net> writes:
> On Fri, Sep 09, 2022 at 04:06:27PM -0700, Junio C Hamano wrote:
>
>> [Cooking]
>>
>> * ab/unused-annotation (2022-09-01) 2 commits
>> (merged to 'next' on 2022-09-08 at dfc6123c6b)
>> + git-compat-util.h: use "deprecated" for UNUSED variables
>> + git-compat-util.h: use "UNUSED", not "UNUSED(var)"
>> (this branch uses jk/unused-annotation.)
>>
>> Undoes 'jk/unused-annotation' topic and redoes it to work around
>> Coccinelle rules misfiring false positives in unrelated codepaths.
>>
>> Will merge to 'master'.
>> source: <cover-0.2-00000000000-20220825T170709Z-avarab@gmail.com>
>
> I just want to double-check that the plan is to merge this to master as
> noted above. I had thought you would revert jk/unused-annotation and
> that I'd just re-roll it. I'm perfectly happy with either, but just
> didn't want to add more confusion by posting that re-roll. ;)
Sorry for making a confusing move. The thing is, the first patch in
this two-patch series builds on top of your "UNUSED(var)" thing.
Its patch text depends on "UNUSED(var)" being there, and it explains
why we ended up using the "var UNUSED" syntax over "UNUSED(var)".
It of course is the right thing to do because "UNUSED(var)" was
already in 'next' when it was written.
We could rewrite it to pretend as if "UNUSED(var)" never happened;
we prefer to keep experiments that turned out to be dead end and we
are unlikely to revisit out of our history. But I think it makes
sense in this case to leave a record in our history that we consider
that "UNUSED(var)" is a superiour implementation that we would have
used and the only reason why we do not use it for now is Coccinelle.
So, 'next' has the merge of 'jk/unused-annotation' reverted, but when
'ab/unused-annotation' was merged, the revert was reverted ;-).
When it graduates to 'master', it will pull 'jk/unused-annotation'
along with it and keeps "UNUSED(var)" in our history, but at its
tip, what we end up using will be "var UNUSED".
next prev parent reply other threads:[~2022-09-12 0:32 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-09-09 23:06 What's cooking in git.git (Sep 2022, #02; Fri, 9) Junio C Hamano
2022-09-10 1:26 ` en/remerge-diff-fixes Elijah Newren
2022-09-10 16:40 ` en/remerge-diff-fixes Junio C Hamano
2022-09-11 5:09 ` What's cooking in git.git (Sep 2022, #02; Fri, 9) Jeff King
2022-09-12 0:32 ` Junio C Hamano [this message]
2022-09-12 0:41 ` Jeff King
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=xmqqo7vlh1pc.fsf@gitster.g \
--to=gitster@pobox.com \
--cc=git@vger.kernel.org \
--cc=peff@peff.net \
/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;
as well as URLs for NNTP newsgroup(s).