[git pull] ieee1394 tree for 2.6.18

[git pull] ieee1394 tree for 2.6.18

[Stefan Richter]

Linus,

the IEEE 1394 subsystem updates for Linux 2.6.18 are now staged in Ben's 
revived linux1394 git tree. I guess the URL to pull from is
git://git.kernel.org/pub/scm/linux/kernel/git/bcollins/linux1394-2.6.git

The updates in there are basically identical to the ieee1394 subsystem 
patches in 2.6.17-rc6-mm2. The essence:
  - a few fixes which did not seem important enough for 2.6.17
  - a performance tweak in the DMA routines
  - enhanced hardware compatibility (with 1394b PHYs when running at
    S100...S400, and with devices with link speed < phy speed)
  - minor coding updates, e.g. partial sem2mutex and kthread conversion

Thanks,
-- 
Stefan Richter
-=====-=-==- -==- =--=-
http://arcgraph.de/sr/

Re: [git pull] ieee1394 tree for 2.6.18

[Linus Torvalds]

On Sun, 18 Jun 2006, Stefan Richter wrote:
> 
> the IEEE 1394 subsystem updates for Linux 2.6.18 are now staged in Ben's
> revived linux1394 git tree. I guess the URL to pull from is
> git://git.kernel.org/pub/scm/linux/kernel/git/bcollins/linux1394-2.6.git

I'm sure that URL works fine, but I want to see what I'm pulling before I 
pull it, so _please_ use one of the scripts that generates diffstats and 
shortlogs, or do it by hand..

		Linus

Re: [git pull] ieee1394 tree for 2.6.18

[Al Viro]

On Mon, Jun 19, 2006 at 07:06:39PM -0700, Linus Torvalds wrote:
> 
> 
> On Sun, 18 Jun 2006, Stefan Richter wrote:
> > 
> > the IEEE 1394 subsystem updates for Linux 2.6.18 are now staged in Ben's
> > revived linux1394 git tree. I guess the URL to pull from is
> > git://git.kernel.org/pub/scm/linux/kernel/git/bcollins/linux1394-2.6.git
> 
> I'm sure that URL works fine, but I want to see what I'm pulling before I 
> pull it, so _please_ use one of the scripts that generates diffstats and 
> shortlogs, or do it by hand..

Hrm...  That's actually one thing git might do - how hard would it be
to teach git-upload-pack to generate the diffstat and shortlog instead
of a pack?  It has all information needed for that, after all...

I mean, _you_ can ask that sort of summary, but when somebody else
wants to take a look at the summary of some branch in remote repository
mentioned on l-k, well...

If that's too much work server-side, could the result of git-fetch-pack -k
be easily postprocessed client-side to get the same result?  That's
easy to undo - just a single rm would do that...

Re: [git pull] ieee1394 tree for 2.6.18

[Linus Torvalds]

On Tue, 20 Jun 2006, Al Viro wrote:
> 
> Hrm...  That's actually one thing git might do - how hard would it be
> to teach git-upload-pack to generate the diffstat and shortlog instead
> of a pack?  It has all information needed for that, after all...

It _does_ do that.  When I do a pull, it shows me what got pulled, and if 
I don't like it, I can just undo it.

But that's not the point.

I want to know what I'm pulling _ahead_ of time, AND I WANT TO KNOW THAT 
WHAT I PULL IS WHAT THE SENDER INTENDED ME TO PULL!

No amount of "git tells me what I pulled" will ever give me either.

If the pushing side cannot be bothered to tell me what the repository 
contains, I really don't want to have anything to do with that repository 
or its maintainer. I want people to tell me what they are sending me, 
because that way both they and I are aware of what to expect.

In other words, this is not about technology. This is about human 
interaction. I do _not_ trust git repositories. I trust the people who 
make those git repositories available, and that means that I want to hear 
from them.

I want them to tell me what they are sending, so that _when_ I pull, I can 
line up the result of that pull with the mail they sent, and I can tell 
"ok, that's actually what the other side intended".

		Linus

Re: [git pull] ieee1394 tree for 2.6.18

[Al Viro]

On Mon, Jun 19, 2006 at 08:14:45PM -0700, Linus Torvalds wrote:
> But that's not the point.
> 
> I want to know what I'm pulling _ahead_ of time, AND I WANT TO KNOW THAT 
> WHAT I PULL IS WHAT THE SENDER INTENDED ME TO PULL!

No arguments; that's a different question.

I'm _not_ saying that you should <something>.

I'm saying that often _I_ am curious about the log _in_ _some_ _remote_ _tree_.
Preferably - without fetch + git log + rm .git/refs/tmp + git prune, which
is how I do that now.  git prune is quite slow, for one thing...

It's not about kernel or getting stuff merged; the question is about git
and cheaper way to do the thing I often find useful.  IOW, read that as
"BTW, is there a way to get such information out of git without too much
PITA?"

Re: [git pull] ieee1394 tree for 2.6.18

[Al Viro]

On Tue, Jun 20, 2006 at 05:22:51AM +0100, Al Viro wrote:
> I'm saying that often _I_ am curious about the log _in_ _some_ _remote_ _tree_.
> Preferably - without fetch + git log + rm .git/refs/tmp + git prune, which
> is how I do that now.  git prune is quite slow, for one thing...
> 
> It's not about kernel or getting stuff merged; the question is about git
> and cheaper way to do the thing I often find useful.  IOW, read that as
> "BTW, is there a way to get such information out of git without too much
> PITA?"

Actually, posting that _was_ useful - staring at the above got me to
realize that git clone -l -s -n + git fetch + git log + rm -rf would
work just fine and be much faster than the variant above...

Still, that looks like excessive from server, if nothing else.  Is there
a better way to do it?  Getting remote log, that is, preferably with
a way to get it starting at the point I have in local tree.

Re: [git pull] ieee1394 tree for 2.6.18

[Roland Dreier]

 > Actually, posting that _was_ useful - staring at the above got me to
 > realize that git clone -l -s -n + git fetch + git log + rm -rf would
 > work just fine and be much faster than the variant above...
 > 
 > Still, that looks like excessive from server, if nothing else.  Is there
 > a better way to do it?  Getting remote log, that is, preferably with
 > a way to get it starting at the point I have in local tree.

In the same vein "git clone --reference <local tree> <remote>" would
be a further optimization, I think.

 - R.

Re: [git pull] ieee1394 tree for 2.6.18

[Russell King]

On Mon, Jun 19, 2006 at 08:14:45PM -0700, Linus Torvalds wrote:
> I want them to tell me what they are sending, so that _when_ I pull, I can 
> line up the result of that pull with the mail they sent, and I can tell 
> "ok, that's actually what the other side intended".

Given that you've complained about me sending daily pull requests
already, how do you intend folk to handle the situation where they've
sent you a pull request, it's apparantly been ignored, and they update
the tree from which you pull (maybe for akpm's benefit) and then you
eventually get around to pulling it a couple of days later?

Given your complaint and your comments above, I can only assume that
I must not touch a tree which I've asked you to pull for 48 hours
just in case you do decide to honour the pull request.

If that's not the case, we need something in place so we know what
your intentions are.  Or we just say "sod it, we'll update the tree
anyway and see what happens, and send an updated request after 48
hours."

-- 
Russell King
 Linux kernel    2.6 ARM Linux   - http://www.arm.linux.org.uk/
 maintainer of:  2.6 Serial core

Re: [git pull] ieee1394 tree for 2.6.18

[Stefan Richter]

Russell King wrote:
> On Mon, Jun 19, 2006 at 08:14:45PM -0700, Linus Torvalds wrote:
>>I want them to tell me what they are sending, so that _when_ I pull, I can 
>>line up the result of that pull with the mail they sent, and I can tell 
>>"ok, that's actually what the other side intended".
> 
> Given that you've complained about me sending daily pull requests
> already, how do you intend folk to handle the situation where they've
> sent you a pull request, it's apparantly been ignored, and they update
> the tree from which you pull (maybe for akpm's benefit) and then you
> eventually get around to pulling it a couple of days later?
[...]

I don't maintain git repos myself, but I'd say _branches_ or something 
like that might be the way to go.
-- 
Stefan Richter
-=====-=-==- -==- =-=--
http://arcgraph.de/sr/

Re: [git pull] ieee1394 tree for 2.6.18

[Russell King]

On Tue, Jun 20, 2006 at 09:29:37PM +0200, Stefan Richter wrote:
> Russell King wrote:
> >On Mon, Jun 19, 2006 at 08:14:45PM -0700, Linus Torvalds wrote:
> >>I want them to tell me what they are sending, so that _when_ I pull, I 
> >>can line up the result of that pull with the mail they sent, and I can 
> >>tell "ok, that's actually what the other side intended".
> >
> >Given that you've complained about me sending daily pull requests
> >already, how do you intend folk to handle the situation where they've
> >sent you a pull request, it's apparantly been ignored, and they update
> >the tree from which you pull (maybe for akpm's benefit) and then you
> >eventually get around to pulling it a couple of days later?
> [...]
> 
> I don't maintain git repos myself, but I'd say _branches_ or something 
> like that might be the way to go.

The point was to try to establish when we could consider the tree from
which we'd asked Linus to pull from as being sufficiently old that it
would not be pulled from without another request being sent - or if it
was pulled from, that we wouldn't get an email from Linus about the fact
there was new stuff in there.

-- 
Russell King
 Linux kernel    2.6 ARM Linux   - http://www.arm.linux.org.uk/
 maintainer of:  2.6 Serial core

Re: [git pull] ieee1394 tree for 2.6.18

[Dave Neuer]

On 6/20/06, Russell King <rmk+lkml@arm.linux.org.uk> wrote:
> On Tue, Jun 20, 2006 at 09:29:37PM +0200, Stefan Richter wrote:
> > Russell King wrote:
> > >On Mon, Jun 19, 2006 at 08:14:45PM -0700, Linus Torvalds wrote:
> > >>I want them to tell me what they are sending, so that _when_ I pull, I
> > >>can line up the result of that pull with the mail they sent, and I can
> > >>tell "ok, that's actually what the other side intended".
> > >
> > >Given that you've complained about me sending daily pull requests
> > >already, how do you intend folk to handle the situation where they've
> > >sent you a pull request, it's apparantly been ignored, and they update
> > >the tree from which you pull (maybe for akpm's benefit) and then you
> > >eventually get around to pulling it a couple of days later?
> > [...]
> >
> > I don't maintain git repos myself, but I'd say _branches_ or something
> > like that might be the way to go.
>
> The point was to try to establish when we could consider the tree from
> which we'd asked Linus to pull from as being sufficiently old that it
> would not be pulled from without another request being sent - or if it
> was pulled from, that we wouldn't get an email from Linus about the fact
> there was new stuff in there.

Can git pull a tag?

Dave

Re: [git pull] ieee1394 tree for 2.6.18

[Al Viro]

On Tue, Jun 20, 2006 at 04:02:43PM -0400, Dave Neuer wrote:
> On 6/20/06, Russell King <rmk+lkml@arm.linux.org.uk> wrote:
> >On Tue, Jun 20, 2006 at 09:29:37PM +0200, Stefan Richter wrote:
> >> Russell King wrote:
> >> >On Mon, Jun 19, 2006 at 08:14:45PM -0700, Linus Torvalds wrote:
> >> >>I want them to tell me what they are sending, so that _when_ I pull, I
> >> >>can line up the result of that pull with the mail they sent, and I can
> >> >>tell "ok, that's actually what the other side intended".
> >> >
> >> >Given that you've complained about me sending daily pull requests
> >> >already, how do you intend folk to handle the situation where they've
> >> >sent you a pull request, it's apparantly been ignored, and they update
> >> >the tree from which you pull (maybe for akpm's benefit) and then you
> >> >eventually get around to pulling it a couple of days later?
> >> [...]
> >>
> >> I don't maintain git repos myself, but I'd say _branches_ or something
> >> like that might be the way to go.
> >
> >The point was to try to establish when we could consider the tree from
> >which we'd asked Linus to pull from as being sufficiently old that it
> >would not be pulled from without another request being sent - or if it
> >was pulled from, that we wouldn't get an email from Linus about the fact
> >there was new stuff in there.
> 
> Can git pull a tag?

Of course, it can.

Re: [git pull] ieee1394 tree for 2.6.18

[Dave Neuer]

On 6/20/06, Al Viro <viro@ftp.linux.org.uk> wrote:
> On Tue, Jun 20, 2006 at 04:02:43PM -0400, Dave Neuer wrote:
> > On 6/20/06, Russell King <rmk+lkml@arm.linux.org.uk> wrote:
> > >
> > >The point was to try to establish when we could consider the tree from
> > >which we'd asked Linus to pull from as being sufficiently old that it
> > >would not be pulled from without another request being sent - or if it
> > >was pulled from, that we wouldn't get an email from Linus about the fact
> > >there was new stuff in there.
> >
> > Can git pull a tag?
>
> Of course, it can.

So "please pull git://somehost/myrepo.git mytag" is a solution?

Dave

Re: [git pull] ieee1394 tree for 2.6.18

[Linus Torvalds]

On Tue, 20 Jun 2006, Dave Neuer wrote:
> > 
> > Of course, it can.
> 
> So "please pull git://somehost/myrepo.git mytag" is a solution?

Yes. As is "mybranch" etc. A lot of people use a special "for-linus" 
branch, which they update when they are ready to push to me, even if they 
might - for example - have a more "wild and crazy" main branch that they 
want others to pull for testing.

On the other hand, it really _is_ more important to just use some common 
sense. This is much less about technology than about a social protocol: 
people you know better you can be less strict with, and you can use slang 
with them, and you can call them "pinhead" rather than "Dr Torvalds". 

So people you work closely with you know how they work, they know you, and 
you may not be a total stickler for protocol.

And other people may your co-workers, but you don't actually talk daily 
with them, and you don't necessarily feel you "know" them, you are a bit 
more careful about. You follow company policy, you work through the 
channels ratehr than just showing up at his door to hang out.

See? There are pretty well-established rules for "please pull", but that 
doesn't mean that they are set in stone per se.  Don't sweat it.

Another way of sayign the same thing, and maybe clarifying: this _is_ 
about the human-to-human interaction. Git on its own can do the 
machine-to-machine part, and if you make the "please pull" be _purely_ 
automated, and you take the rules mindlessly, then you'd be kind of 
missing the point of the whole thing, wouldn't you?

So there's a protocol in place. But it's a _social_ protocol. Everybody 
starts out extra stiff and extra careful. But some day, you can give me a 
wedgie, ok?

			Linus

Re: [git pull] ieee1394 tree for 2.6.18

[Stefan Richter]

Russell King wrote:
> The point was to try to establish when we could consider the tree from
> which we'd asked Linus to pull from as being sufficiently old that it
> would not be pulled from without another request being sent - or if it
> was pulled from, that we wouldn't get an email from Linus about the fact
> there was new stuff in there.

You could /a/ try to come to an agreement with him about a less brittle 
protocol, or /b/ think of your mail as an "announcement" rather than a 
"request" (for your peace of mind) and follow up with a repost of the 
announcement if you come to know that your updates did not appear in 
Linus' tree when the end of a merge window is near.

(Of course I cannot really assess your requirements and workload, not 
being maintainer of a large or highly connected kernel component myself. 
So ignore if I'm suggesting something stupid here.)
-- 
Stefan Richter
-=====-=-==- -==- =-=--
http://arcgraph.de/sr/

Re: [git pull] ieee1394 tree for 2.6.18

[Stefan Richter]

I wrote:
> Russell King wrote:
>> The point was to try to establish when we could consider the tree from
>> which we'd asked Linus to pull from as being sufficiently old that it
>> would not be pulled from without another request being sent - or if it
>> was pulled from, that we wouldn't get an email from Linus about the fact
>> there was new stuff in there.
> 
> You could /a/ try to come to an agreement with him about a less brittle 
> protocol, or /b/ think of your mail as an "announcement" rather than a 
> "request" (for your peace of mind) and follow up with a repost of the 
> announcement if you come to know that your updates did not appear in 
> Linus' tree when the end of a merge window is near.
...and simply post a new announcement when _you_ saw fit to update your 
outbound tree.
-- 
Stefan Richter
-=====-=-==- -==- =-=--
http://arcgraph.de/sr/

Re: [git pull] ieee1394 tree for 2.6.18

[Al Viro]

On Tue, Jun 20, 2006 at 10:57:10PM +0200, Stefan Richter wrote:
> Russell King wrote:
> >The point was to try to establish when we could consider the tree from
> >which we'd asked Linus to pull from as being sufficiently old that it
> >would not be pulled from without another request being sent - or if it
> >was pulled from, that we wouldn't get an email from Linus about the fact
> >there was new stuff in there.
> 
> You could /a/ try to come to an agreement with him about a less brittle 
> protocol, or /b/ think of your mail as an "announcement" rather than a 
> "request" (for your peace of mind) and follow up with a repost of the 
> announcement if you come to know that your updates did not appear in 
> Linus' tree when the end of a merge window is near.

c) no matter how badly your variant of git might suck, on server you
can always do
	echo [commit-ID] > .git/refs/heads/for-linus-<date>
and ask him to pull that branch from that server (if your version of
git doesn't suck, git checkout -b for-linus-<date>; git checkout <your
previous branch> will do it).

Then move on with the life, using whatever you are using.  The question when
to remove that file... hell, run "trim the stuff more than month old"
from cron every month and forget about it.

Re: [git pull] ieee1394 tree for 2.6.18

[Ryan Anderson]

On Tue, Jun 20, 2006 at 10:15:24PM +0100, Al Viro wrote:
> (if your version of
> git doesn't suck, git checkout -b for-linus-<date>; git checkout <your
> previous branch> will do it).

git branch for-linus-<date> HEAD

-- 

Ryan Anderson
  sometimes Pug Majere

Re: [git pull] ieee1394 tree for 2.6.18

[Linus Torvalds]

On Tue, 20 Jun 2006, Russell King wrote:
> 
> Given that you've complained about me sending daily pull requests
> already, how do you intend folk to handle the situation where they've
> sent you a pull request, it's apparantly been ignored

It's not ignored, btw, I'm staggering the merging so that I don't merge 
everything the first day - I want nightly snapshots to have a chance of 
making a difference to people who aren't git users but test patches.

(In other words, I want "2.6.17-git1" and "2.6.17-git2" etc to actually 
b esomewhat spread out - rather than merge everything when people send it 
to me the first day after a release. I also tend to want a release to be 
"left alone" for a day or so, so that even people who track the 
development tree religiously will actually end up testing it).

> Given your complaint and your comments above, I can only assume that
> I must not touch a tree which I've asked you to pull for 48 hours
> just in case you do decide to honour the pull request.

Actually, from a technical standpoint, the easy way to do this with git is 
to simply have different branches (or even tags).

That said, people who I merge up with often (and you're one of them), and 
I don't actually tend to have any issues with (and again, you're one of 
them), I don't mind it I pull and notice that there's been an added commit 
or two since you asked me to pull.

Again - the "please pull" message is because I want to work with the 
_person_, and I want to be comfortable that what I pull is what they 
intended to pull.

And as you can guess, trees that I constantly update from end up having 
much less of that issue - there's less risk of there being 
miscommunication or just plain mistakes in those kinds of setups _anyway_.

So in many ways, if it's an archive that doesn't sync up very often, I 
want such people to be _extra_ careful. When I get a pull request for 
ieee1394, _especially_ as the maintainer kind of seems to keep on 
changing, I want to be a lot more careful than with something like yours 
or Davids trees, that I've worked with for years beforehand, and have 
already been using git pretty much since day one etc etc.

In other words: rules are rules, and in the end, they matter a hell of a 
lot less than just common sense. But they matter _more_ for the repo 
maintainers I haven't gotten used to.

			Linus

Re: [git pull] ieee1394 tree for 2.6.18

[Stefan Richter]

Linus Torvalds wrote:
> On Sun, 18 Jun 2006, Stefan Richter wrote:
>> 
>> the IEEE 1394 subsystem updates for Linux 2.6.18 are now staged in Ben's
>> revived linux1394 git tree. I guess the URL to pull from is
>> git://git.kernel.org/pub/scm/linux/kernel/git/bcollins/linux1394-2.6.git
> 
> I'm sure that URL works fine, but I want to see what I'm pulling before I 
> pull it, so _please_ use one of the scripts that generates diffstats and 
> shortlogs, or do it by hand..

Here are stat and shortlog; not from the actual git tree but from patches as
they went in. Side notes: The spike in the diffstat is whitespace formatting.
Sem2mutex and kthread conversions as well as suspend/resume fixes are not
complete yet.

 Documentation/feature-removal-schedule.txt |    4
 drivers/ieee1394/Kconfig                   |   13
 drivers/ieee1394/csr1212.c                 |    2
 drivers/ieee1394/csr1212.h                 |    1
 drivers/ieee1394/dma.c                     |   18
 drivers/ieee1394/eth1394.c                 |   51 +-
 drivers/ieee1394/eth1394.h                 |    2
 drivers/ieee1394/highlevel.c               |  445 +++++++++------------
 drivers/ieee1394/hosts.c                   |    7
 drivers/ieee1394/hosts.h                   |   19
 drivers/ieee1394/ieee1394_core.c           |   62 +-
 drivers/ieee1394/ieee1394_transactions.c   |   10
 drivers/ieee1394/nodemgr.c                 |   61 ++
 drivers/ieee1394/ohci1394.c                |   37 +
 drivers/ieee1394/ohci1394.h                |   10
 drivers/ieee1394/raw1394.c                 |   54 +-
 drivers/ieee1394/sbp2.c                    |   85 +---
 drivers/ieee1394/sbp2.h                    |   23 -
 drivers/ieee1394/video1394.c               |   16
 19 files changed, 463 insertions(+), 457 deletions(-)

Alexey Dobriyan:
	eth1394: endian fixes

Arjan van de Ven:
	Semaphore to mutex conversion.

Christoph Hellwig, Andrew Morton:
	ieee1394_core: switch to kthread API

Daniel Drake:
	video1394: be quiet

Jean-Baptiste Mur:
	ieee1394/ohci1394: CycleTooLong interrupt management

Jim Westfall:
	ieee1394: speed up of dma_region_sync_for_cpu

Jody McIntyre:
	Update feature removal of obsolete raw1394 ISO requests.

Robert Hancock:
	Fix broken suspend/resume in ohci1394

Stefan Richter:
	eth1394: replace __constant_htons by htons
	ieee1394: adjust code formatting in highlevel.c
	ieee1394: hl_irqs_lock is taken in hardware interrupt context
	ieee1394: add preprocessor constant for invalid csr address
	ieee1394: extend lowlevel API for address range properties
	ieee1394: save RAM by using a single tlabel for broadcast transactions
	ieee1394: support for slow links or slow 1394b phy ports
	ohci1394: make phys_dma parameter read-only
	ohci1394: set address range properties
	ohci1394: Remove superfluous call to free_dma_rcv_ctx,
	raw1394: fix whitespace after x86_64 compat patch
	sbp2: Kconfig fix
	sbp2: fix deregistration of status fifo address space
	sbp2: use __attribute__((packed)) for on-the-wire structures
	sbp2: provide helptext for CONFIG_IEEE1394_SBP2_PHYS_DMA and mark it experimental
	sbp2: fix S800 transfers if phys_dma is off
	sbp2: remove ohci1394 specific constant
	sbp2: log number of supported concurrent logins
	sbp2: remove manipulation of inquiry response
	sbp2: make TSB42AA9 workaround specific to Momobay CX-1

-- 
Stefan Richter
-=====-=-==- -==- =-=--
http://arcgraph.de/sr/

Re: [git pull] ieee1394 tree for 2.6.18

[Linus Torvalds]

On Tue, 20 Jun 2006, Stefan Richter wrote:
> 
> Here are stat and shortlog; not from the actual git tree but from patches as
> they went in. Side notes: The spike in the diffstat is whitespace formatting.
> Sem2mutex and kthread conversions as well as suspend/resume fixes are not
> complete yet.

Ok, I pulled, and pushed out, but this tree is really problematic: the 
authorship info has been dropped entirely, it looks.

Git tries to make it very easy to attribute patches properly (with command 
line switches to do it manually, but also with automated tools like git-am 
etc to do it automatically from emails), and has separate "committer" and 
"author" fields, exactly so that you can see both who did the actual 
patch, and who actually merged it.

The ieee1394 tree doesn't actually do that. Ben Collins shows up as the 
author for all of it.

Yes, the sign-offs look fine, but still, attribution and credit is 
_important_.

So for next time, please spend the effort to get attribution right, ok?

		Linus

Re: [git pull] ieee1394 tree for 2.6.18

[Ben Collins]

On Tue, 2006-06-20 at 20:07 -0700, Linus Torvalds wrote:
> 
> On Tue, 20 Jun 2006, Stefan Richter wrote:
> > 
> > Here are stat and shortlog; not from the actual git tree but from patches as
> > they went in. Side notes: The spike in the diffstat is whitespace formatting.
> > Sem2mutex and kthread conversions as well as suspend/resume fixes are not
> > complete yet.
> 
> Ok, I pulled, and pushed out, but this tree is really problematic: the 
> authorship info has been dropped entirely, it looks.

Sorry about that. Was caused by the patches coming in to me in non-git,
non-mbox form, and me not taking the time to do each one by hand. Wont
be like that after this.

-- 
Ubuntu     - http://www.ubuntu.com/
Debian     - http://www.debian.org/
Linux 1394 - http://www.linux1394.org/
SwissDisk  - http://www.swissdisk.com/

Re: [git pull] ieee1394 tree for 2.6.18

[Stefan Richter]

Ben Collins wrote:
> On Tue, 2006-06-20 at 20:07 -0700, Linus Torvalds wrote:
>> Ok, I pulled, and pushed out, but this tree is really problematic: the 
>> authorship info has been dropped entirely, it looks.
> 
> Sorry about that. Was caused by the patches coming in to me in non-git,
> non-mbox form, and me not taking the time to do each one by hand. Wont
> be like that after this.

Yes, I pointed Ben to patch files which lacked original rfc822 headers.
Sorry for causing trouble.

A related question: If a patch written by author A is forwarded via
e-mail by person B to git tree maintainer C, and C imports the mail with
git-am or git-applymbox --- will git catch the _last_ "From: " line
(hopefully listing the address of A) or the first "From: " line (which
contains the forwarding address of B) as author of the patch?

Similarly, will it care for the last or first "Subject: " line? (The
first line being the actual mail header, the last being a line in the
mail body or a line in a plain-text encoded attachment, that is.)

Thanks,
-- 
Stefan Richter
-=====-=-==- -==- =-=-=
http://arcgraph.de/sr/

Re: [git pull] ieee1394 tree for 2.6.18

[Ben Collins]

On Wed, 2006-06-21 at 11:49 +0200, Stefan Richter wrote:
> A related question: If a patch written by author A is forwarded via
> e-mail by person B to git tree maintainer C, and C imports the mail with
> git-am or git-applymbox --- will git catch the _last_ "From: " line
> (hopefully listing the address of A) or the first "From: " line (which
> contains the forwarding address of B) as author of the patch?

If you forward me email-patches as attachments I can work off that
attachment as an email directly, so that should be ok.

-- 
Ubuntu     - http://www.ubuntu.com/
Debian     - http://www.debian.org/
Linux 1394 - http://www.linux1394.org/
SwissDisk  - http://www.swissdisk.com/

Re: [git pull] ieee1394 tree for 2.6.18

[Junio C Hamano]

Stefan Richter <stefanr@s5r6.in-berlin.de> writes:

> A related question: If a patch written by author A is forwarded via
> e-mail by person B to git tree maintainer C, and C imports the mail with
> git-am or git-applymbox --- will git catch the _last_ "From: " line
> (hopefully listing the address of A) or the first "From: " line (which
> contains the forwarding address of B) as author of the patch?
>
> Similarly, will it care for the last or first "Subject: " line? (The
> first line being the actual mail header, the last being a line in the
> mail body or a line in a plain-text encoded attachment, that is.)

The main question was answered by Ben, so this may be a bit
offtopic, but I'll answer git questions anyway.

The author-name-email, subject, and author-date are taken from
the RFC2822 headers of the e-mail the committer feeds git-am,
but you can override them by having "From: ", "Subject: ", and
"Date: " as the first lines of the message body, like this:

    From: "For W. Arder" <forwarder@example.com>
    Date: Wed, 21 Jun 2006 11:49:22 +0200
    Subject: forwarding patch (was Re: ieee1394)
    Message-ID: ...

    From: Stefan Richter <stefanr@s5r6.in-berlin.de>
    Date: Mon Jun 12 18:16:25 2006 -0400
    Subject: eth1394: replace __constant_htons by htons

    ...and __constant_ntohs, __constant_ntohl, __constant_cpu_to_be32 too
    where possible.  Htons and friends are resolved to constants in these
    places anyway.  Also fix an endianess glitch in a log message, spotted
    by Alexey Dobriyan.

    Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de>

Note that the latter three header-looking lines are not RFC2822
headers but part of your (eh, Mr Arder's) message body.