From: Ingo Molnar <mingo@elte.hu>
To: Stefan Richter <stefanr@s5r6.in-berlin.de>
Cc: Julia Lawall <julia@diku.dk>, Sam Ravnborg <sam@ravnborg.org>,
Manish Katiyar <mkatiyar@gmail.com>,
LKML <linux-kernel@vger.kernel.org>,
kernel-janitors@vger.kernel.org
Subject: Re: [PATCH] Remove errors caught by checkpatch.pl in kernel/kallsyms.c
Date: Mon, 16 Feb 2009 18:21:47 +0100 [thread overview]
Message-ID: <20090216172147.GB26995@elte.hu> (raw)
In-Reply-To: <499995C4.3070504@s5r6.in-berlin.de>
* Stefan Richter <stefanr@s5r6.in-berlin.de> wrote:
> Julia Lawall wrote:
> > Is everything below the --- preserved in what is available via git log?
>
> No, none of it (if the patch is mechanically applied with e.g. git-am).
>
> Sometimes, useful information does indeed get lost because an author
> didn't consider it "above ---"-worthy.
>
> ...
> > I think the how information has some value,
> > both to make people aware of what tools are useful for what kinds of
> > tasks, and to help one understand what criteria were used in making the
> > patch.
>
> That information is perfect for conservation mailing list archives.
Uhm, a mailing list archives have numerous well-known disadvantages:
they are not permanent or accessible in any acceptable fashion - URLs
can go stale, certain mails get lost, the commit itself has no backlink
to the lkml discussion [or whichever of the hundreds of maintainer lists
it was discussed on], etc. etc.
Claiming that information is 'perfect' for the mailing list but not good
for the Git log is a double standard.
The thing is, we need more information about how a given patch was
originated, not less. We need more information about how efficient our
tools are, not less.
The main problems we have with commit logs today is not too much
information but too little information. A log message should be
well-structured, with the more important information near the top of it,
the less important information at the end - but arguing that something
as fundamental as the tools that motivated a change is silly on its
face.
Ingo
next prev parent reply other threads:[~2009-02-16 17:22 UTC|newest]
Thread overview: 20+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-02-15 18:34 [PATCH] Remove errors caught by checkpatch.pl in kernel/kallsyms.c Manish Katiyar
2009-02-15 18:47 ` Sam Ravnborg
2009-02-15 18:47 ` Manish Katiyar
2009-02-16 13:07 ` Stefan Richter
2009-02-16 13:28 ` Ingo Molnar
2009-02-16 14:00 ` Stefan Richter
2009-02-16 14:19 ` Ingo Molnar
2009-02-16 15:22 ` Stefan Richter
2009-02-16 15:41 ` Manish Katiyar
2009-02-16 15:50 ` Ingo Molnar
2009-02-16 16:13 ` Stefan Richter
2009-02-16 17:12 ` Ingo Molnar
2009-02-16 18:04 ` Stefan Richter
2009-02-16 16:13 ` Al Viro
2009-02-16 17:11 ` Ingo Molnar
2009-02-16 14:28 ` Paolo Ciarrocchi
2009-02-16 16:17 ` Julia Lawall
2009-02-16 16:35 ` Stefan Richter
2009-02-16 17:21 ` Ingo Molnar [this message]
2009-02-16 17:15 ` Ingo Molnar
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=20090216172147.GB26995@elte.hu \
--to=mingo@elte.hu \
--cc=julia@diku.dk \
--cc=kernel-janitors@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=mkatiyar@gmail.com \
--cc=sam@ravnborg.org \
--cc=stefanr@s5r6.in-berlin.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox