[gst-devel] Git commit messages

[Felipe Contreras]

On Sat, Jan 31, 2009 at 4:27 PM, Tim-Philipp Müller <t.i.m at zen.co.uk> wrote:
> Hi all,
>
> maybe I'm alone with this, but I think it'd be nice if our commit
> message summary lines were a bit more self-explanatory.
>
> In particular, I think it'd be nice if we could start prefixing the
> summary lines with the plugin/element/baseclass in question, e.g.
>
>  playbin: fix this and that
>  blademux: ..
>  basesrc: ...
>  controller: ...
>
> or the like. This would make it easier to see from the commit messages /
> summary lines whether a commit is 'interesting' or not, and to separate
> signal from noise, and to generally follow what's going on. (Yes, I'm
> aware that the changed files are listed both in gitk/giggle and in the
> commit mail.)
>
> In the same vein, please don't use words like 'here' in a summary line
> ('Don't do this here' is not a great summary), and make it clear whether
> code was changed or not (e.g. 'Fix typo' could mean code or docs).

+1

>From git documentation:
Though not required, it's a good idea to begin the commit message
with a single short (less than 50 character) line summarizing the
change, followed by a blank line and then a more thorough description.
Tools that turn commits into email, for example, use the first line
on the Subject: line and the rest of the commit in the body.

Also, many other tools benefit from a short single line summary (gitk,
cgit, etc.)

Besides, it would be great if we could have some basic guideline: 6
months from now, would I be able to understand what the commit is
doing and why by just reading the message?

-- 
Felipe Contreras