Re: [rtems commit] 2011-03-02 Ralf Cors épius <ralf.corsepius at rtems.org>
gedare at rtems.org
Sat Mar 3 18:23:16 UTC 2012
On Fri, Mar 2, 2012 at 10:12 PM, Ralf Corsepius
<ralf.corsepius at rtems.org> wrote:
> On 03/02/2012 08:51 PM, Thomas Doerfler wrote:
>> Am 02.03.2012 19:12, schrieb Ralf Corsepius:
>>> On 03/02/2012 06:22 PM, Gedare Bloom wrote:
>>>> Please provide useful shortlog messages so that your commits do not
>>>> all look the same when viewed through the vc-list or git log and
>>>> related tools.
>>> Again, fix your crappy script!
>>>> If you feel compelled to include a ChangeLog in your
>>>> commit message that is fine as long as a useful shortlog appears
>>> I do not intend to diverge a mu from what is established practice in
>>> GCC, binutils, newlib and what has been extabished practice in RTEMS for
>>> ca. 15 year.
>>> No regards,
>> RTEMS is a ather slow moving project.
> Well, I don't see this. It's moving at the usual speed of "non-toy
>> Anyway if we stay in a tool
>> environment and a colaboration model that has been define d15 years ago,
>> we will be frozen and nonfuctional soon.
> WTH does a tool which generates "shortlogs", which some people consider to
> be unreadable, to do with a project's progress?
All that I have asked is that you provide a useful shortlog. I don't
care if you also provide a ChangeLog message to your commit message,
or any other additional details that make the commit easier to
understand. Because the VCS stores the relevant information about what
has changed, your ChangeLog commit messages are largely redundant.
This argument is really about git vs cvs, and that you have been
unable to adapt to use the new tool effectively yet. The shortlog just
happens to be the most obvious problem right now.
CVS is an outdated tool that prevents or makes difficult many useful
development patterns including sharing code, branching/merging,
creating patch sets, reading development history, continuous
integration, and more. I don't know about you, but I went from having
about 20 copies of the RTEMS CVS repository on my desktop computer to
manage all my different RTEMS-related projects to now only needing a
I did not advocate the switch to git, nor did I participate in making
it happen, although I did agree with the reasoning given for why we
should do it. Now that I am adapting to git I am appreciating more and
more the capabilities that it brings.
> The "Deluxe Loginfo"-generated "shortlogs" from CVS were plain dates".
> change log for rtems (2011-12-09)
> change log for rtems (2011-12-10)
> Was this better readable? No, they weren't!
Correct, the CVS descriptions were not readable/useful.
> git's shotlogs are simply the first line of a changelog text block.
> [rtems commit] Use alternative API
> [rtems commit] Remove (Obsolete).
> Are these better readable than the deluxe-loginfo shortlogs?
> No, they aren't and never will be!
You just said the CVS descriptions were not better readable, and now
you have said the git shortlogs are not better readable. Anyway, I
would assert that the git shortlog is much better readable when
developers provide useful commit messages.
Consider the following table of commits from the web interface
Age Commit message Author Files Lines
24 hours 2011-03-02 Ralf Corsépius
<ralf.corsepius at rtems.org>HEADmaster Ralf Corsépius 2 -0/+5
28 hours 2011-03-02 Ralf Corsépius <ralf.corsepius at rtems.org> Ralf
Corsépius 4 -17/+30
30 hours 2012-03-02 Ralf Corsépius <ralf.corsepius at rtems.org> Ralf
Corsépius 2 -182/+193
33 hours 2012-03-02 Ralf Corsépius <ralf.corsepius at rtems.org> Ralf
Corsépius 3 -1/+11
3 days PR2028: Milkymist USB: forward MIDI messages. Werner Almesberger 2 -0/+12
9 days Fix typo in comment. Joel Sherrill 1 -1/+1
9 days Merge remote-tracking branch 'upstream/master' Jennifer Averett 3 -9/+4
9 days Avoid NULL dereference in printk() before libchip console
initialized Jennifer Averett 4 -63/+129
9 days psxtests: Fix typo in psxstat Sebastian Huber 1 -1/+1
9 days LPC32XX: Typo Sebastian Huber 1 -1/+1
Similar data appears in my inbox. The git shortlog is a standard way
for tools to obtain a useful description of a changeset. Can you
really tell me that your commit messages are more useful than the
>> There had been many changes in the past, some of them requiring a
>> different way to use RTEMS and interact with the community. Therefore I
>> don't understand your attitude to simply ignore the changes that the
>> majority of the RTEMS community appreciates.
> Because I feel "this majority" is making noise about nothing ... these
> shortlogs do not cause any malfunctions and are not better readable.
> Conversely, these shortlogs are just a symptom of me keeping the VCS's
> internal changelog entries in consistent and readable form.
Your commits are consistent but they are not readable. Certainly the
shortlog versions are not. I do not so much mind when I can issue git
log and see the entire message of your commit that includes the
changelog entry that you wrote. But when I am just looking through the
history in order to find a particular change these entries are opaque
and worthless for searching.
> That said, I consider people having commited changes to RTEMS without
> ChangeLog-file changes to be sloppy quality of works. Openly said, if I had
> to decide, I would insist on them being reverted and resubmitted, because
> these changes are causing massive usabilty regressions.
Ditto to your commits with their useless shortlog messages.
>> I remember situations where patches coming from me or my colleagues have
>> been rejected by you, because they did not conform to the formalites ad
>> requirements defined by the community.
> Yes, and the problem is? It's in the nature of reviews of also occasionally
> having to reject some things.
> It's the difference between "one-man show/toy-projects" and real-projects.
>> Can you please explain why you now take the right to commit
>> non-conforming patches and instead insult other people?
> I do not see I insulted Gedare. I feel his remarks originate from
> inexperience of lack of understanding of the importance of ChangeLog-files
> and of a VCS's internal ChangeLogs.
You told me to fix my crappy script, which by the way is not my
script, and said you had no regards for me. This would probably insult
a person who cared about the things that you say. But I am beyond that
point, although I have not yet reached the point of completely
ignoring you because you do occasionally make sense.
I noticed that your commits to the rtems-crossrpms repository have
useful commit messages. So you obviously understand that using a
description in the first line of a git commit is the right thing to do
in order to use the VCS tool well. Yet for the rtems repository you
continue to submit rubbish commit messages. Such behavior is that of a
petulant child, and I hope that you grow up.
More information about the devel