<div dir="ltr"><br><div class="gmail_extra"><br><br><div class="gmail_quote">On Sun, Jun 29, 2014 at 8:05 AM, Glynn Clements <span dir="ltr"><<a href="mailto:glynn@gclements.plus.com" target="_blank">glynn@gclements.plus.com</a>></span> wrote:<br>

<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class=""><br>
Vaclav Petras wrote:<br>
<br>
> please read, comment and follow:<br>
><br>
> <a href="http://trac.osgeo.org/grass/wiki/Submitting/General#Commitmessages" target="_blank">http://trac.osgeo.org/grass/wiki/Submitting/General#Commitmessages</a><br>
<br>
</div>Personally, I don't favour duplicating information which is stored<br>
elsewhere (e.g. which files are affected).<br>
<br>
The auto-generated emails list the affected files, as does the Trac<br>
"Timeline" page. In the source browser, revision logs are generated<br>
for specific files and directories.<br>
<br></blockquote><div>If you refer to file names, I hope I wrote there that they should not be included. If you refer to the prefix with library/module/component name, I are right that it is a duplication but I think that it is also summary of the file list.<br>

</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
> fix bug introduced in r60216<br>
> (missing information how the bug was fixed and which bug it was)<br>
<br>
If a commit has a bug, and a subsequent commit fixes it shortly<br>
afterwards, before any ticket has been opened or before anyone else<br>
has commented on it or even noticed it, there's really no need to<br>
include the details (anyone wanting them can look at the diff itself).<br>
<br>
Commit summaries should, IMHO, be sufficient to identify a specific<br>
commit given that you already know roughly what you're looking for.<br>
E.g. if you know that something broke in particular way in a given<br>
interval, the summaries should help to identify which commits are<br>
"likely suspects" worthy of closer examination.<br> 
<br></blockquote><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
If you know that something broke in r1234, then "fixed bug in r1234"<br>
should be all you need to identify the commit you're looking for.<br>
<br>
If you're familiar with the code, its structure and its history, you<br>
don't need anything more. If you aren't, you're probably going to need<br>
to read the actual diff, and a verbose summary won't change that.<br>
<span class="HOEnZb"><font color="#888888"><br></font></span></blockquote><div>I cannot agree, commit messages are here to learn about the commit and perhaps even something in general. If I'm reading some code and I don't understand why this is there (because there is no explicit comment) I can see blame/annotate with a commit message saying why this was added/changed.<br>

<br>However, if there is just ticket number I have to go to the ticket, read it and think how it relates to the diff which might be tough (remember some of the long multi-topic tickets). If there is a "fix bug introduced in r1234" I have no idea which bug. If some missing library is added to Makefile I can perhaps guess a build issue but with some additional call of some function or addition of parameter I have no clue, was it flickering in NVIZ or compilation error?<br>

<br></div><div>I acknowledge that this is really opinion based and there is a lot of different opinions but I think that we should not ask people to study tickets to understand why is our commit useful. The issue might be sometimes even more apparent with references to older commits when we ask other people to read the diff, and maybe even switch to that revision to find what was the bug we are referring to.<br>

<br></div><div>Vaclav<br></div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="HOEnZb"><font color="#888888">
--<br>
Glynn Clements <<a href="mailto:glynn@gclements.plus.com">glynn@gclements.plus.com</a>><br>
_______________________________________________<br>
grass-dev mailing list<br>
<a href="mailto:grass-dev@lists.osgeo.org">grass-dev@lists.osgeo.org</a><br>
<a href="http://lists.osgeo.org/mailman/listinfo/grass-dev" target="_blank">http://lists.osgeo.org/mailman/listinfo/grass-dev</a><br>
</font></span></blockquote></div><br></div></div>