> For reference, there are two basic reasons for not referring to > bugzilla when sending patches, in the commit log or otherwise. The > first one is that patches should stand on their own. If the bug > contains important information that's relevant to the patch, that > should be included directly in the commit log. If it doesn't, well, > the reference it just redundant. The other reason is that it's not > unlikely that the commit log will outlive bugzilla. I.e., you can't > depend on bugzilla always being there. That's essentially the same > reason as for not including hyperlinks in comments, although at least > the source code can easily be changed, while for the commit log that > would be a serious pain.
I am confused. Following this list only, I so far did not notice someone saying "don't tell the bug number" (ok, might be my fault), but a few times asking the question "does this patch fix an actual" bug. Also, SubmittingPatches says: === ... Include a description ... If you're working on a bug in bugzilla, mention the bug number, and consider filing a bug if none exists. === Maybe this is a misunderstanding of terminology? 'commit log' is for me the combination of the single-line 'header' plus the 'description', which can be multiple paragraphs. (and is usually dropped when patches are imported to the official repo. Why is that BTW?) I would agree, that the bug number should not be in the header, but having it as additional information besides the regular description should not really hurt? Kind regards, Wolfram