Felipe Contreras <felipe.contreras@xxxxxxxxx> 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.
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html