From: Catalin Marinas <catalin.marinas@arm.com>
To: u-boot@lists.denx.de
Subject: [U-Boot-Users] Re: [PATCH] Make target for all ARM supplied and supported development boards - patch 007
Date: Mon, 10 Oct 2005 10:22:53 +0100 [thread overview]
Message-ID: <tnxirw5ybde.fsf@arm.com> (raw)
In-Reply-To: <20051007163927.2D27A353CD2@atlas.denx.de> (Wolfgang Denk's message of "Fri, 07 Oct 2005 18:39:27 +0200")
Wolfgang Denk <wd@denx.de> wrote:
> 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.
Scripts like 'git applymbox' or 'stg import --mail' can do this
automatically. With StGIT you can even modify the patch multiple times
before you decide to permanently store it in your repository.
> 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.
[...]
> 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.
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
(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).
> 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.
Nobody prevents you from looking at the patch before applying it, or
for applying it on a development branch and just moving it to the
stable one (or just temporary applying them with StGIT and, if they
prove to be OK, 'stg commit' to store them permanently).
> But thanks for the well-meant suggestion.
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
want to automate the patch importing, I can help you with some
scripts (or StGIT advice).
Regards,
--
Catalin
next prev parent reply other threads:[~2005-10-10 9:22 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2005-10-07 12:55 [U-Boot-Users] [PATCH] Make target for all ARM supplied and supported development boards - patch 007 Peter Pearse
2005-10-07 13:53 ` Wolfgang Denk
2005-10-07 14:53 ` [U-Boot-Users] " Catalin Marinas
2005-10-07 16:39 ` Wolfgang Denk
2005-10-10 9:22 ` Catalin Marinas [this message]
2005-10-10 11:25 ` Wolfgang Denk
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=tnxirw5ybde.fsf@arm.com \
--to=catalin.marinas@arm.com \
--cc=u-boot@lists.denx.de \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.