svn commit: r278718 - in stable/9: etc/rc.d sbin share/man/man4 share/mk sys/modules/geom tools/build/mk tools/build/options

[Justin T. Gibbs]

On Feb 16, 2015, at 9:11 AM, John Baldwin <jhb at freebsd.org> wrote:
> 
…

> 
> On a more general note, if I'm merging a change with several followup fixes, I 
> 
…

>  2) I don't cut and paste all N logs verbatim.  This tends to be very hard to read.

I used to feel this way too until I started to see the many varied ways that our downstream consumers import our revision history.  For folks who only import a single branch at a time or use a revision control system that can’t easily pull in the original change text from all integrated revisions, removing any content from the merge log is a problem.  Even when you do import all the data and have really good tools for parsing it, it is nice when a naive search (a log of just the current branch) is enough for you to find what you need.

Merges should also be made easier, not harder.  It is one thing to require the change text to be edited to accurately reflect the content of the merge (e.g. differences to maintain ABI compatibility, or the exclusion of hunks that aren’t appropriate for the target of the merge).  But to require them to be summarized just because the reader may have read the original change in another location just adds more work, both for the person doing the merge and the future user of the revision data.

—
Justin