[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20140917154918.GB12190@thunk.org>
Date: Wed, 17 Sep 2014 11:49:18 -0400
From: Theodore Ts'o <tytso@....edu>
To: Milosz Tanski <milosz@...in.com>
Cc: Benjamin LaHaise <bcrl@...ck.org>,
Dave Chinner <david@...morbit.com>,
Jeff Moyer <jmoyer@...hat.com>,
LKML <linux-kernel@...r.kernel.org>,
Christoph Hellwig <hch@...radead.org>,
"linux-fsdevel@...r.kernel.org" <linux-fsdevel@...r.kernel.org>,
linux-aio@...ck.org, Mel Gorman <mgorman@...e.de>,
Volker Lendecke <Volker.Lendecke@...net.de>,
Tejun Heo <tj@...nel.org>
Subject: Re: [PATCH 7/7] check for O_NONBLOCK in all read_iter instances
On Wed, Sep 17, 2014 at 11:33:35AM -0400, Milosz Tanski wrote:
>
> My workflow has been to use git format-patch (1.7.9.5 was shipped with
> my distro), edit the cover letter then use and mutt to send the
> generated emails. Before that I used git apply to import the patches
> that Christoph sent me. I thought about it too, but hand editing the
> email generated by format-patch to essentially having me take credit
> for this sounded like a shady thing to do. The updated version of
> git's (2.1.0) format-patch doesn't change the from email address field
> either.
That's because it gets handled in git send-email. The resulting
e-mail gets sent like this:
From: Subsystem Maintainer <tytso@....edu>
To: LKML list <linux-ext4@...r.kernel.list>
Subject: [PATCH] ext4: foobie blart
From: Original Author <wenqing.lz@...bao.com>
Long commit description which gets placed as the third line of the
commit description, with the subject line as the first line of the
commit description, and the 2nd line being blank.
And then git am handles this correctly, attributing the patch
authorship to Original Author, with the git committer set to the
Subsystem Maintainer who ran the "git am" command.
> The submitting patches document doesn't really describe what to do if
> you take patches / collaborate with somebody else or how to credit the
> original author. It only deals with the case of a subsystem
> maintainers editing the submitters code to fix it up.
The short version is, use a non-prehistoric version of git, and use
"git format-patch" and "git send-email", and be happy. :-)
It's not that hard to build your own version of git, if you are forced
to use some enterprise/LTS/Debian stable distro that can't be bothered
to update git for you.
Cheers,
- Ted
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists