Hi Michael,
The intention of per-file or per-function comments is to have a deeper
explanation of code changes, as opposed to overall explanation of what the
change does at the top. Not every patch needs it, but many do. These are very
helpful in my experience.
* Source/WebCore/animation/CSSTransition.h: Use const AtomString& for the
return value of transitionProperty to cut down on reference count churn.
Use nameString, moved isCSSTransition to private.
Never heard the phrase "GNU changelog" before! But not sure if they are any
less relevant with version control than without.
As for stale commit messages, we can probably have some tooling that does a
more intelligent job, regenerating them while preserving the original comments.
- Alexey
17 нояб. 2022 г., в 3:23 PM, Michael Catanzaro via webkit-dev
написал(а):
Hi,
I'd like to remove the GNU changelog from the bottom of the commit messages by
default. With "by default" I mean people who prefer to use the GNU changelog
for formatting their commit messages would have to change git-webkit
configuration to keep using it, and it would go away for everyone else's commit
messages. I don't see any reason to prohibit the changelogs if really desired,
but these were designed for an era before version control existed, to explain
what is being changed rather than why. The freeform commit message that we add
above the changelogs is usually a better way to explain commits.
(Another disadvantage is it is really easy for the changelog to become stale by
mistake. When amending commits, you have to look closely at the bottom of the
commit message template prepared by git-webkit to notice the updated changelog,
then manually replace the original commit message's changelog. I'm sure we
commit inaccurate changelogs all the time because we forget to do this.)
Michael
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev
