From: Jeff King <peff@peff.net>
To: Junio C Hamano <gitster@pobox.com>
Cc: git@vger.kernel.org
Subject: Re: What's cooking in git.git (Sep 2022, #02; Fri, 9)
Date: Sun, 11 Sep 2022 20:41:14 -0400 [thread overview]
Message-ID: <Yx6AKkWKa5sCUJzM@coredump.intra.peff.net> (raw)
In-Reply-To: <xmqqo7vlh1pc.fsf@gitster.g>
On Sun, Sep 11, 2022 at 05:32:31PM -0700, Junio C Hamano wrote:
> > 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".
OK, I am happy with that. When I rewrote the initial commit to go to
"var UNUSED" instead of "UNUSED(var)", I was going to explain the
alternatives in the commit message. But doing it this way is less work
for me. ;)
I've converted my further annotation patches to "var UNUSED" already, so
those will appear that way from the get-go. If we ever go back to
UNUSED(var), the initial ones are just a "git revert" away, but the new
ones will have to be converted manually. It's not too bad to do it with
a clever use of sed/perl, though.
-Peff
prev parent reply other threads:[~2022-09-12 0:41 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
2022-09-12 0:41 ` Jeff King [this message]
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=Yx6AKkWKa5sCUJzM@coredump.intra.peff.net \
--to=peff@peff.net \
--cc=git@vger.kernel.org \
--cc=gitster@pobox.com \
/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).