On Sat, Jan 31, 2009 at 4:27 PM, Tim-Philipp Müller <
[hidden email]> 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
------------------------------------------------------------------------------
This SF.net email is sponsored by:
SourcForge Community
SourceForge wants to tell your story.
http://p.sf.net/sfu/sf-spreadtheword_______________________________________________
gstreamer-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gstreamer-devel
Locked
