<div dir="ltr">Hi,<div class="gmail_extra"><br><div class="gmail_quote">On Sat, Jul 27, 2013 at 2:07 PM, Milian Wolff <span dir="ltr"><<a href="mailto:mail@milianw.de" target="_blank">mail@milianw.de</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">This commit could also be cleaned up:<br>
commit 722457052892e3a79f40f82f3f2e005abcd3f91d<br>
Author: Vlas Puhov <<a href="mailto:vlas.puhov@mail.ru">vlas.puhov@mail.ru</a>><br>
Date:   Sat Jul 20 16:15:00 2013 +0400<br>
<br>
    BreakpointWidget: Show only file's name, the tooltip shows the full path</blockquote><div><br></div><div style>Adding to what Milian said, commits should have a short description of what it does in the first line, followed by an empty line and then followed by an explanation of _why_ the commit is done. That is, what bug it fixes and why it fixes it (just a bugnumber is often too little), why a given feature is useful or why some improvement makes the application better. This is crucial to be able to determine in the future why a certain change was done, either to be able to apply a similar thing elsewhere or to decide what to do in case a commit causes a bug elsewhere.</div>
<div style><br></div><div style>I've been working on codebases with commits such as the above one and its impossible to safely  change some things because the author - even if available - has no clue anymore why he did something after 5 years. So its always a bit of playing a game of chance when doing such changes and this game is played on the backs of the userbase.</div>
<div> </div><div style>Andreas</div></div></div></div>