Hi,
I created new git tree for the ALSA project at:
rsync://rsync.kernel.org/pub/scm/linux/kernel/git/perex/alsa.git
This tree is intended for pushing ALSA changes to Linus
and will follow the kernel development/release cycles once synced for
the first time. It contains all latest patches from ALSA 1.0.9 now.
I will create another repository (probably alsa-devel.git)
for testing the latest ALSA driver changes (suited for the -mm kernels).
Jaroslav
-----
Jaroslav Kysela <[email protected]>
Linux Kernel Sound Maintainer
ALSA Project, SUSE Labs
On Fri, 27 May 2005, Jaroslav Kysela wrote:
>
> I created new git tree for the ALSA project at:
>
> rsync://rsync.kernel.org/pub/scm/linux/kernel/git/perex/alsa.git
Your scripts(?) to generate these things are a bit strange, since they
leave an extra empty line in the commit message, which confuses at least
gitweb (ie just look at
http://www.kernel.org/git/?p=linux/kernel/git/perex/alsa.git;a=summary
and note how the summary thing looks empty).
Now, arguably gitweb should ignore whitespace at the beginning, but
equally arguably your commits shouldn't have them either...
Linus
On Fri, May 27, 2005 12:13 pm, Linus Torvalds said:
> On Fri, 27 May 2005, Jaroslav Kysela wrote:
>>
>> I created new git tree for the ALSA project at:
>>
>> rsync://rsync.kernel.org/pub/scm/linux/kernel/git/perex/alsa.git
>
> Your scripts(?) to generate these things are a bit strange, since they
> leave an extra empty line in the commit message, which confuses at least
> gitweb (ie just look at
>
> http://www.kernel.org/git/?p=linux/kernel/git/perex/alsa.git;a=summary
>
> and note how the summary thing looks empty).
>
> Now, arguably gitweb should ignore whitespace at the beginning, but
> equally arguably your commits shouldn't have them either...
>
Perhaps git should enforce this? Patch attached.
Remove leading empty lines from commit messages.
Signed-off-by: Sean Estabrooks <[email protected]>
On Fri, 27 May 2005, Sean wrote:
> >
> > Now, arguably gitweb should ignore whitespace at the beginning, but
> > equally arguably your commits shouldn't have them either...
>
> Perhaps git should enforce this? Patch attached.
>
> Remove leading empty lines from commit messages.
>
> Signed-off-by: Sean Estabrooks <[email protected]>
I'm not sure.
The thing is, right now git allows binary commit messages if somebody
really wants to. Now, a lot of the _tools_ end up only printing up to the
first '\0' or something, but in general, maybe somebody actually wants to
embed his own strange stuff in there (eg use encryption but still use
standard git tools).
Which makes me worry. So I _do_ do whitespace cleanup in my "apply email
patches" scripts, but I'm not sure whether the core should care about the
data that people feed it, even for commit messages.
Opinions?
Linus
On Fri, 27 May 2005, Linus Torvalds wrote:
> On Fri, 27 May 2005, Jaroslav Kysela wrote:
> >
> > I created new git tree for the ALSA project at:
> >
> > rsync://rsync.kernel.org/pub/scm/linux/kernel/git/perex/alsa.git
>
> Your scripts(?) to generate these things are a bit strange, since they
> leave an extra empty line in the commit message, which confuses at least
> gitweb (ie just look at
>
> http://www.kernel.org/git/?p=linux/kernel/git/perex/alsa.git;a=summary
>
> and note how the summary thing looks empty).
Okay, sorry for this small bug. I'll recreate the ALSA git tree with
proper comments again. Also, the author is not correct (should be taken
from the first Signed-off-by:).
Jaroslav
-----
Jaroslav Kysela <[email protected]>
Linux Kernel Sound Maintainer
ALSA Project, SUSE Labs
On Fri, 27 May 2005, Jaroslav Kysela wrote:
>
> Okay, sorry for this small bug. I'll recreate the ALSA git tree with
> proper comments again. Also, the author is not correct (should be taken
> from the first Signed-off-by:).
Hmm.. That's not always true in general, since Sign-off does allow to sign
off on other peoples patches (see the "(b)" clause in DCO), but maybe in
the ALSA tree it is.
Are you coming from a CVS tree or what? It's clearly not my patch
applicator thing, since that one removes spaces, I'm pretty sure.
Linus
>>>>> "LT" == Linus Torvalds <[email protected]> writes:
LT> On Fri, 27 May 2005, Sean wrote:
>> >
>> > Now, arguably gitweb should ignore whitespace at the beginning, but
>> > equally arguably your commits shouldn't have them either...
>>
>> Perhaps git should enforce this? Patch attached.
>>
>> Remove leading empty lines from commit messages.
>>
>> Signed-off-by: Sean Estabrooks <[email protected]>
LT> I'm not sure.
LT> Opinions?
Porcelains and gitweb should play with each other nicely, but
the core should _not_ care by default.
An extra option ("--text", perhaps) to git-commit-tree is
acceptable to me, and it may be even a good thing to have. It
would make life a bit easiear for Porcelain writers if nothing
else. If that is to happen, I would say we could do more than
just leading blank line removal. We can also remove trailing
blanks before each LF, tabify indented log message contents, and
remove empty lines before EOF.
Linus Torvalds <[email protected]> wrote:
>
>
>
> On Fri, 27 May 2005, Jaroslav Kysela wrote:
> >
> > Okay, sorry for this small bug. I'll recreate the ALSA git tree with
> > proper comments again. Also, the author is not correct (should be taken
> > from the first Signed-off-by:).
>
> Hmm.. That's not always true in general, since Sign-off does allow to sign
> off on other peoples patches (see the "(b)" clause in DCO), but maybe in
> the ALSA tree it is.
Yes, I'll occasionally do patches which were written by "A" as:
From: A
...
Signed-off-by: B
And that comes through email as:
...
From: <[email protected]>
...
From: A
...
Signed-off-by: B
which means that the algorithm for identifying the author is "the final
From:".
I guess the bug here is the use of From: to identify the primary author,
because transporting the patch via email adds ambiguity.
Maybe we should introduce "^Author:"?
>>>>> "AM" == Andrew Morton <[email protected]> writes:
AM> I guess the bug here is the use of From: to identify the primary author,
AM> because transporting the patch via email adds ambiguity.
AM> Maybe we should introduce "^Author:"?
While we are at it, we probably would want "^Author-Date:" as
well.
On Fri, 27 May 2005, Andrew Morton wrote:
> Linus Torvalds <[email protected]> wrote:
> >
> >
> >
> > On Fri, 27 May 2005, Jaroslav Kysela wrote:
> > >
> > > Okay, sorry for this small bug. I'll recreate the ALSA git tree with
> > > proper comments again. Also, the author is not correct (should be taken
> > > from the first Signed-off-by:).
> >
> > Hmm.. That's not always true in general, since Sign-off does allow to sign
> > off on other peoples patches (see the "(b)" clause in DCO), but maybe in
> > the ALSA tree it is.
>
> Yes, I'll occasionally do patches which were written by "A" as:
>
> From: A
> ...
> Signed-off-by: B
>
> And that comes through email as:
>
>
> ...
> From: <[email protected]>
> ...
> From: A
> ...
> Signed-off-by: B
>
>
> which means that the algorithm for identifying the author is "the final
> From:".
>
> I guess the bug here is the use of From: to identify the primary author,
> because transporting the patch via email adds ambiguity.
>
> Maybe we should introduce "^Author:"?
>
That might be good. I honestly don't know what would be the best
solution, but what happens often at the moment is that patches get passed
on as "From" whatever maintainer (or random resender) happened to pass it
on to Andrew/Linus and that person then effectively gets labeled as the
author of the patch in the changelogs/git/whatever. That's not perfect...
Author: might solve it.. worth a shot if you ask me..
--
Jesper Juhl
On 27/05/05, Andrew Morton <[email protected]> wrote:
> Yes, I'll occasionally do patches which were written by "A" as:
>
> From: A
> ...
> Signed-off-by: B
>
> And that comes through email as:
>
> ...
> From: <[email protected]>
> ...
> From: A
> ...
> Signed-off-by: B
>
> which means that the algorithm for identifying the author is "the final
> From:".
>
> I guess the bug here is the use of From: to identify the primary author,
> because transporting the patch via email adds ambiguity.
>
> Maybe we should introduce "^Author:"?
How about "^Written-by:"? That seems to fit in much more nicely with
"Signed-off-by:".
--
schnee
On Fri, 27 May 2005, Andrew Morton wrote:
>
> Yes, I'll occasionally do patches which were written by "A" as:
>
> From: A
> ...
> Signed-off-by: B
>
> And that comes through email as:
>
>
> ...
> From: <[email protected]>
> ...
> From: A
> ...
> Signed-off-by: B
>
>
> which means that the algorithm for identifying the author is "the final
> From:".
No, the algorithm is:
- the email author, _or_ if there is one, the top "From:" in the body.
And the rule is that you never remove (or add to) an existing From:, since
the author doesn't change from being passed around.
Put another way: authorship is very different from sign-off. The sign-off
gets stacked, the authorship is constant, and thus the rules are
different.
Also, authorship is more important than sign-off-ship, so authorship goes
at the top, while sign-offs go at the bottom.
> I guess the bug here is the use of From: to identify the primary author,
> because transporting the patch via email adds ambiguity.
No it doesn't, the email "from" just ends up being the "default" if no
explicit authorship is noted.
> Maybe we should introduce "^Author:"?
It would still have the same rules, so it wouldn't change anything but the
tag, so I don't think there is any real advantage to it.
Linus
Linus Torvalds <[email protected]> wrote:
>
> > which means that the algorithm for identifying the author is "the final
> > From:".
>
> No, the algorithm is:
> - the email author, _or_ if there is one, the top "From:" in the body.
That all assumes that the tools are smart enough to separate the email
headers from the body :(
On Fri, 27 May 2005, Andrew Morton wrote:
>
> That all assumes that the tools are smart enough to separate the email
> headers from the body :(
Well, _that_ is trivial: the first empty line is the marker between header
and body.
This is a stupid awk program to do this:
/^From: / { name=$0 }
state==1 { print name; exit }
/^$/ { state=1 }
Or something.
Linus
On Fri, May 27, 2005 at 03:46:25PM -0700, Andrew Morton wrote:
> That all assumes that the tools are smart enough to separate the email
> headers from the body :(
the first blank line separates these, sed can do that --- so is it
really a problem?
On Fri, 27 May 2005, Jaroslav Kysela wrote:
> On Fri, 27 May 2005, Linus Torvalds wrote:
>
> > On Fri, 27 May 2005, Jaroslav Kysela wrote:
> > >
> > > I created new git tree for the ALSA project at:
> > >
> > > rsync://rsync.kernel.org/pub/scm/linux/kernel/git/perex/alsa.git
> >
> > Your scripts(?) to generate these things are a bit strange, since they
> > leave an extra empty line in the commit message, which confuses at least
> > gitweb (ie just look at
> >
> > http://www.kernel.org/git/?p=linux/kernel/git/perex/alsa.git;a=summary
> >
> > and note how the summary thing looks empty).
>
> Okay, sorry for this small bug. I'll recreate the ALSA git tree with
> proper comments again. Also, the author is not correct (should be taken
> from the first Signed-off-by:).
The ALSA git tree is updated with all fixes now. I had an old git version
which inserted this extra line at top of comments.
Also, it seems that there's a delay between master.kernel.org and git web
interface at http://www.kernel.org (the changes are not on web yet).
Jaroslav
-----
Jaroslav Kysela <[email protected]>
Linux Kernel Sound Maintainer
ALSA Project, SUSE Labs