From mboxrd@z Thu Jan 1 00:00:00 1970 From: Theodore Ts'o Date: Wed, 08 Jul 2015 15:03:35 +0000 Subject: Re: Clarification for the use of additional fields in the message body Message-Id: <20150708150335.GB20551@thunk.org> List-Id: References: <559B85CD.6040200@users.sourceforge.net> <559BBDD6.7040808@users.sourceforge.net> <559BFB19.2080700@users.sourceforge.net> <559CCC9D.8050606@users.sourceforge.net> <559CED4C.1080402@users.sourceforge.net> In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: Julian Calaby Cc: SF Markus Elfring , Frans Klaver , Greg Kroah-Hartman , Chris Park , Dean Lee , Johnny Kim , Rachel Kim , linux-wireless , "devel@driverdev.osuosl.org" , Julia Lawall , kernel-janitors@vger.kernel.org, LKML On Wed, Jul 08, 2015 at 09:05:53PM +1000, Julian Calaby wrote: > If multiple people are submitting identical changes, then the one that > is applied is the one the maintainer sees first, which will most > likely be determined by which one hit their inbox / list first. Nobody > is going to look at timestamps in emails to determine which one will > be applied. And some maintainers may choose *not* to act on a patch first, even if they see it first. They might be focused on bug fix patches, and not act on cleanup or feature patches until -rc3 or rc4. Or maybe they will use separate branches for "urgent_for_linus" patches, so two different patchs may end up in completely different git flows. > If you're worried about which one of several versions of a patch will > be applied, change the subject to [PATCH v2] ..... instead of [PATCH] > .... for the second version. *Please* do this. In fact, this is the one thing I wish git send-email would do automatically, along with having a place to edit and track the 0/N summary patch. > >> To be honest, I've only ever used that timestamp for reporting > >> purposes at work, and I'd be surprised if anyone was doing anything > >> other than that with them. > > > > Thanks for your detailed feedback. Note also that some maintainers have work flow that deliberately smash the date (i.e., because they are using a system such as guilt), so if you are depending on the submitted timestamp, it's going to break on you. - Ted