Commit messages

[Ralf Corsepius]

On 01/24/2012 05:07 PM, Thomas Doerfler wrote:
> Hi,
>
> Am 24.01.2012 16:32, schrieb Ralf Corsepius:
>> On 01/24/2012 10:53 AM, Thomas Doerfler wrote:
>>> Hi,
>>>
>
>>> So wouldn't it be possibe to generate the Changelogs (maybe in a
>>> slightly modified format) automatically now, based on the commit
>>> messages and other info in the GIT repository?
>>
>> Then you likely are able to explain
>> * how you want to _replace_ bogus changelog entries,
>
> Hm, let me think:
>
> The comment attached to a git patch/commit is part of the patch.

People will not be able to commit patches without using git?

I've seen this happening with other git hype victim projects, which are 
rejecting changes from people who are not using git. To me this is 
inacceptable.

> It's
> not just decorum, it is needed to maintain the patch. So a git patch
> without a proper comment should not be accepted.
Please understand that this is not acceptable to me - because this 
approach is  closing out people who are not using git.


> I don't know how such a patch replacement lokks like in the resulting,
> automatically generated changelog. But even if  this stays visible in
> the documentation (".... patch removed due to inappropriate comment....
> ", " ... replacement for patch XXX, now with proper comment...") I see
> no harm in it.

My issue is seeing ChangeLog populated up with "correction logs".

i.e. something like this:

* 03.01.12: Thomas Dörfler: Revert last changelog entry.

* 02.01.12: Tomas Dörfler: Revert last changelog entry.

* 01.01.12: Fomas Förpfler: Wrong commit message.


I want a proper ChangeLog entry:

* 01.01.12: Thomas Dörfler: Correct changelog entry.


>> * how you want to cope handle rtems CVS history.
>
> The simplest way would be to leave to existing ChangeLogs in place as a
> "monument of history". They will maintain changelog info for the
> CVS-based design phase of RTEMS.
>
> There may be more intelligent ways to integrate the CVS ChangeLog info
> together with the CVS history into git.
Without automated git changelogs, we would have ChangeLogs as before.

>>> It seems other projects also went that way.
>> Please take into consideration, git currently is an _overrated hype_, so
>> you'll likely find many people, who are following it.
>>
>> Don't get me wrong, I am not opposed to using git, but I am not naive
>> enough to blindly follow this hype.
>
> It would do great harm to the RTEMS project if we all would jump on
> every fancy train/hype coming by without thinking, whether this hype is
> a benefit or not for the project. So it is good to ask the questions you
> ask. OTOH git overcomes some problems, e.g. related to distributed
> development, that we carry along for a long time now.
No disagreement. We were right in not jumping onto the SVN, hg or bzr 
trains - But I am far from being convinced about git.

And yes, distributed development is an enduser advantage - It's easier 
to fork away - That said, if RTEMS was using git before, RTEMS likely 
would have forked and moved to github in early January.

Ralf