On 11/18/19 12:11 PM, Segher Boessenkool wrote:
Hi Richard,
On Mon, Nov 18, 2019 at 04:48:03PM +0000, Richard Earnshaw (lists)
wrote:
On 18/11/2019 15:55, Segher Boessenkool wrote:
That immediately shows some of the shortcomings of this approach: the
subject line is much too long, but more importantly, it doesn't make
much sense: it is not what the patch does, it is the description of a
bug that is related in some way to this patch. It is not uncommon
for
a commit to not fix the problem mentioned in the bug report (if it
*is*
a problem!), or not fix it completely.
Then again, changing all such subject lines to read "patch" could
also
already be considered an improvement.
Well the real question is whether such a summary is worse than the
current situation of just printing the author in the wrong field. I
personally don't think it is.
I think that non-obviously-wrong-but-still-wrong info is not something
we should introduce. And, I think this will happen a *lot*.
Maybe you can just put in artificial subjects like "Patch related to
PR12345" or the like? That is correct, displays a lot better, and is
at least as useful (imo).
I don't see but other projects mention PRS or Bugzilla ids but
more common in my experience is just mentioned the commit
ids. For example this fixes commit id x introducing PR x. Commit
ids are know good so having them linked in commit messages
is much easier to track then PRs, I can just use git log -p commit id.
There are about 560 commits where the code highlights that the data
might be suspect (usually a category mismatch).
What about commits that mention multiple PRs? What do you do for
those?
(Are there as many of those as I think, anyway?) With normally very
short
subjects you could put all of them in there :-)
See my above but for this you would just state the main issue(s) in
the commit
message and in the body what commits/PRs are being handled.
Not sure if that works for everyone but that's normally the best way
in my
experience,
Nick
Sorry but cced the others as this was a misclick.