From: Felipe Contreras <felipe.contreras@gmail.com>
To: Junio C Hamano <gitster@pobox.com>,
Felipe Contreras <felipe.contreras@gmail.com>
Cc: git@vger.kernel.org,
"brian m . carlson" <sandals@crustytoothpaste.net>,
"Martin Ågren" <martin.agren@gmail.com>,
"Jeff King" <peff@peff.net>,
"Ævar Arnfjörð Bjarmason" <avarab@gmail.com>
Subject: Re: [PATCH v3 3/5] doc: remove unnecessary rm instances
Date: Tue, 25 May 2021 17:13:45 -0500 [thread overview]
Message-ID: <60ad769938b70_294de208fc@natae.notmuch> (raw)
In-Reply-To: <xmqqim36eo12.fsf@gitster.g>
Junio C Hamano wrote:
> Felipe Contreras <felipe.contreras@gmail.com> writes:
>
> > Junio C Hamano wrote:
> >> Felipe Contreras <felipe.contreras@gmail.com> writes:
> >> > * helped-by: 17% (1336)
> >>
> >> I actually think people use this one to say "person X gave a
> >> valuable input in the review discussion", which is exactly the case
> >> here, and that was why I wondered you needed to invent a completely
> >> new one.
> >
> > I think the opposite: "helped-by" encompasses virtually anything...
>
> But your own stats disagrees with your opinion, so don't invent a
> new thing, period.
Stats don't have opinions.
You and I have had this discussion before, between the status quo:
die ("could not find author in commit %s",
oid_to_hex(&commit->object.oid));
And:
die("could not find author in commit %s",
oid_to_hex(&commit->object.oid));
Eventually you yourself updated the documentation to explicitly state
that it's fine to not align the subsequent lines to the opening
parenthesis: f26443da04 (CodingGuidelines: on splitting a long line,
2014-05-02).
It is wrong to demand something that is not in the guidelines,
especially if later on the guidelines might include the very thing
supposedly frowned upon [*].
In this particular case the guideline is not missing, it actually sides
with me:
You can also create your own tag or use one that's in common usage
such as "Thanks-to:", "Based-on-patch-by:", or "Mentored-by:".
If you want to forbid certain commit trailers--or limit the allowed
trailers to a sanctioned list--then update the guidelines first to
reflect that.
But I don't think it makes sense to do that, because commit
trailers--just like words, and hundreds of other things--follow a Zipf's
law, where the 10th most common word appears around 1/10th of the time.
If you graph the frequency of commit trailers vs. a Zipf distrubtion
with a 80:20 rule, it follows it almost perfectly [1]. That means 80% of the
commit trailers appear 20% of the time.
My script can calculate any quantile and for example found out that just
two lines--Acked-by and Reviewed-by--acound for 47% of all the lines.
They are the top 1%.
The top 10% is constituted by 16 lines, and the top 25% are 33.
The median is 1 appearance. That means of the 155 unique lines, half of
them have just 1 appearance, in fact, more than half: 100 of them.
For more details see the mail I just sent [2].
Unsurprisingly commit trailer lines follow the same pattern as income
distribution and musical bands popularity; the rich get richer.
As much as you might despise the poorest among commit trailers, they are
the majority, and they will keep being the majority.
Cheers.
[1] https://i.imgur.com/1wQgSlP.png
[2] https://lore.kernel.org/git/60ad75ac7ffca_2ae08208b@natae.notmuch/
[Footnote]
* Granted, my patch back then did not match the new guideline
perfectly, but also it wasn't wrong for reasons stated then.
--
Felipe Contreras
next prev parent reply other threads:[~2021-05-25 22:13 UTC|newest]
Thread overview: 21+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-05-21 22:29 [PATCH v3 0/5] doc: asciidoc cleanups Felipe Contreras
2021-05-21 22:29 ` [PATCH v3 1/5] doc: refactor common asciidoc dependencies Felipe Contreras
2021-05-21 22:29 ` [PATCH v3 2/5] doc: improve " Felipe Contreras
2021-05-21 22:29 ` [PATCH v3 3/5] doc: remove unnecessary rm instances Felipe Contreras
2021-05-24 17:51 ` Junio C Hamano
2021-05-24 18:40 ` Felipe Contreras
2021-05-24 18:45 ` Felipe Contreras
2021-05-25 2:59 ` Junio C Hamano
2021-05-25 6:54 ` Felipe Contreras
2021-05-25 17:11 ` Junio C Hamano
2021-05-25 22:13 ` Felipe Contreras [this message]
2021-05-26 0:24 ` Felipe Contreras
2021-05-21 22:29 ` [PATCH v3 4/5] doc: simplify Makefile using .DELETE_ON_ERROR Felipe Contreras
2021-05-21 22:29 ` [PATCH v3 5/5] doc: avoid using rm directly Felipe Contreras
2021-05-24 17:51 ` [PATCH v3 0/5] doc: asciidoc cleanups Junio C Hamano
2021-05-27 14:32 ` Jeff King
2021-05-27 16:59 ` Felipe Contreras
2021-05-27 17:09 ` Jeff King
2021-05-27 17:35 ` Felipe Contreras
2021-05-28 0:02 ` Junio C Hamano
2021-05-28 1:12 ` Felipe Contreras
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=60ad769938b70_294de208fc@natae.notmuch \
--to=felipe.contreras@gmail.com \
--cc=avarab@gmail.com \
--cc=git@vger.kernel.org \
--cc=gitster@pobox.com \
--cc=martin.agren@gmail.com \
--cc=peff@peff.net \
--cc=sandals@crustytoothpaste.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).