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 <webkit-dev@lists.webkit.org> написал(а):

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