lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<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

Powered by Openwall GNU/*/Linux Powered by OpenVZ