Subject: Re: [PATCH] branch: use $curr_branch_short more

From: Junio C Hamano <[email-masked]>
Date: Tue, 03 Sep 2013 09:56:35 -0700

Felipe Contreras <[email-masked]> writes:

>> Subject: branch: use $curr_branch_short more
>
> Why? I don't think that summary explains the reason for being for this
> patch, also, it starts with branch: instead of pull:
>
> Subject: pull: trivial simplification
>
> With that summary, people would have an easier time figuring out if
> they need to read more about the patch or not.

People, other than the author of the patch, use the subject line in
different ways.  It is unclear to me which usage the "trivial lets
them decide if it needs further reading" is trying to help.

 1. Those running "shortlog" to see how much impact each contributor
    had.

 2. Those viewing list of Subjects in their MUA to see which is
    worth reading and commenting on.

 3. Those viewing list of Subjects in their MUA to see which is
    worth reading and applying to their trees.

 4. Those trying to resolve conflicts during "git am -3" and "git
    merge" [*1*].

 5. Those who find that a commit broke the build after bisecting,
    and want to see what is the reasoning behind the broken change.

 6. Those who find an interesting section of the code, blamed its
    origin to a commit, and want to see what is the reasoning behind
    the broken change.

There may be others, but the above should cover most of the cases, I
think.

For 1., they may discount anything that says "trivial" as "not of
high impact".  There may be trivial but high impact changes, but I
do not know how much this mischaracterization hurts.  Probably not
that much.

For 2., they may either skip "trivial", thinking "if it is trivial,
it must be correct", or read "trivial", thinking "the author thinks
trivial, it is likely there are holes in the author's thinking".
Among the 6 patches in $gmane/233472 "Trivial cleanups and fixes",

 - 1, 2, 4 and 5 were trivially correct and good,
 - 3 was not a clear improvement,
 - 6 was wrong.

This is totally unscientific but if we take them as a representative
set of "trivial" patches, a "trivial" patch is correct only about
4.5/6 = 75% of the time.  As a consequence, people who do want to
help the project are better off reading "trivial" just like others,
so that breakages in the 25% do not go unnoticed.  The label does
not let them skip, and wastes one line that possibly could have
given them more information with non-descriptive word "trivial".

For 3., unless the author wants such a patch skipped and dropped on
the floor, "marking it 'trivial' to allow them skip" would not make
much sense, and with 75% success rate, it would be irresponsible for
those who apply patches not to read a "trivial" and blindly apply
it.  Labelling it "trivial" only wastes one line that possibly could
have given them more information with non-descriptive word "trivial".

For 4., 5., and 6., "allow them to skip" will not be in the picture,
as they already know they are interested in that particular change.
Labelling it "trivial" only wastes one line that possibly could have
given them more information with non-descriptive word "trivial"

So it seems to me that a title "trivial" only helps those running
"shortlog" to discount weight of contributor's contribution.

And the author who does not want to spend time on coming up with a
good title, but for each patch, there are a lot more readers than a
single author of that patch, so the benefit to the author does not
count much.

[Footnote]

*1* The former shows the title of the patch and the latter shows the
    branch name after a conflict marker, and it helps to have as
    much clue as possible to remind what is attempted on each side
    of the change.  It is a responsibility for the person who does
    the merge to give the branch a descriptive name, and the branch
    that queued a "trivial" patch does not have to be named
    "trivial", but the title of the patch is a large part of the
    input to naming the branch.