git.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
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

  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).