Rockbox mail archive
Subject: Re: jdgordon: r28078 - trunk/apps/radio
Re: jdgordon: r28078 - trunk/apps/radio
2010/9/15 Jonathan Gordon <jdgordy_at_gmail.com>:
> On 15 September 2010 23:39, Rafaël Carré <rafael.carre_at_gmail.com> wrote:
>> 2010/9/15 Jonathan Gordon <jdgordy_at_gmail.com>:
>>> When is it read? users only read it when it happens (or soon (<6m)
>>> afterwards ) to see what development they might have missed, probably
>>> looking for keywords of interest to them. Devs (speaking from my
>>> experience here) do the users thing, but when the message is actually
>>> important is when you are trying to track down a possible breaking
>>> change, and even then (as I said a few replies ago) the message isnt
>>> even the first thing I look for.) And then when I find a possible
>>> change I look at the diff before rereading the message (because I know
>>> it cant possibly explain everything).
>> It happens frequently to me that I'm reading the full log of a particular file
>> or folder (with or without the diff), and especially when it's an area that I
>> don't know.
>> Please think that all your logs can and will be read in years from now and
>> any info which could help the future devs to understand the code is nice.
>> It's quite frequent that you are trying to understand why a line of code was
>> committed 8 years ago and you wish the committer had explained better
>> what he did. (ok perhaps not very frequent but it did happen to me and
>> other people in different projects)
> This is another problem entirely which is impossible to fix unless we
> require commit message reviews. enabling log changing isnt going to
> fix it either (except for when it is blatantly wrong and completely
> accidental). This is no different to trying to write the actual code
> so it is understandable 8 years later. "you" understand it now, and
> "you" will understand it then so whats the big deal, right?
I'm not trying to "fix" that, I just spent a lot of time trying to understand
particular old pieces of code and I try to do my best to avoid this pain to
potential future developers :)
It's a personal choice though and I don't require that other devs do the same
but of course if they want to do it then it's even better
For example I can imagine something like:
A: *commits something
B: hey what is XXX in your commit I don't get it
A: here's the explanation: "foo bar"
B: mind if I add that "foo bar" to the commit log so it's more clear?
A: sure, go ahead
I think if we enable this and use the same rules than for reverting
commits it'd be fine
(Don't edit the log of someone else commit unless the other agreed or
didn't answer in some days)
Received on 2010-09-15
Page was last modified "Jan 10 2012" The Rockbox Crew