Dear Catalin,

in message tnxbr21v0no.fsf@arm.com you wrote:

A suggestion - since you are using GIT, you could automatically generate the changelog from the patch comments and no longer keep this

I would still need to copy & paste the information from the message, and collect submitter name and date from the mail headers. I think it is impoortant to be able to match a change to the original posting of the submitter on the mailing list.

In this respect, the CHANGELOG entry is a condensed form of the patch comments with additional information about the sugbmitter which I need in any case - no matter if I explicitely register it in a CHANGELOG file or not.

file under revision control. People using GIT would just run gitk or git log to see what has changed. For people using snapshot or releases, you would would put the changelog in the tarball.

Please note that I also continue to keep the CVS server at SF in sync with all development going on on the main branch of the git repository. This is another place where the CHANGELOG file comes in handy.

It's even easier if you only accept patches in text/plain format and use GIT (or other tools on top) to automatically import the patches from the saved e-mail (the author information being automatically preserved).

It would be easier for me, indeed - much easier, as I would have to reject 98% of all submitted patches.

Also, I am strictly against automatically importing unchecked patches. Too many patches contain horrible nonsense and would basicly corrupt the repository. And if I have to process / filter the paches anyway, then it does not make any difference if I run this command or that one.

But thanks for the well-meant suggestion.

Best regards,

Wolfgang Denk

In message tnxirw5ybde.fsf@arm.com you wrote:

Scripts like 'git applymbox' or 'stg import --mail' can do this automatically. With StGIT you can even modify the patch multiple times

Yes, I know. And it works fine if the submitted patchs follow th required conventions. But it is no exception here to receive a base64 encoded file "patch.bz2" which turns out to be a bzip2-compressed _tarball_ containing the patch plus eventually other files like the CHANGELOG entry.

As mentioned before: either I have to reject 90...95% of all patches because they cannot be processed automatically, or I have to do this stuff manually.

You have a pre-commit hook in GIT which you can use to automatically append part of the patch description and author to the changelog file

Yes, I know that such options exist, but I have to admit that I did not understand the documentation:

The default pre-commit hook, when enabled, catches introduction of lines with trailing whitespaces and aborts the commit when a such line is found.

?

(like for Linux, you can ask people to have a short description on the first line or two, followed by an empty line and followed by a longer description).

"I can call spirits from the vasty deep." "Why so can I, or so can any man; but will they come when you do call for them?" - Shakespeare, 1 King Henry IV, Act III, Scene I.

I mean: as long as we cannot have people understand the requested CHANGELOG entry format (if they include such an entry at all), what is the chance that they will do what we ask for? :-(

All that matters is how you are used to work, it's pretty hard to change the work-flow after using it for years. Anyway, in case you

Indeed.

want to automate the patch importing, I can help you with some scripts (or StGIT advice).

I will certainly have to look into StGIT again.

Best regards,

Wolfgang Denk