On Wed, Jul 08, 2015 at 05:27:38PM +0200, SF Markus Elfring wrote:
> > 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.
>
Hi Markus,
On Wed, Jul 8, 2015 at 11:46 PM, SF Markus Elfring
wrote:
>> Is there truly no way to simplify that process?
>
> I see some software development possibilities which could improve
> the communication with high volume mailing lists.
You shouldn't need any software development, most peop
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 t
> 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.
Thanks for your hint.
I am just trying to offer the possibility for the re
> Is there truly no way to simplify that process?
I see some software development possibilities which could improve
the communication with high volume mailing lists.
> You should be sending the patches directly with SMTP using git-send-email,
This tool is also fine for the publishing of a lot o
Hi Markus,
On Wed, Jul 8, 2015 at 7:28 PM, SF Markus Elfring
wrote:
>> If it's harmless, then no, but in this case, people are questioning
>> why you're adding it as it adds no value
>
> Some Git software developers care to keep the information complete
> for the author commit.
>
>
>> to anyone a
> If it's harmless, then no, but in this case, people are questioning
> why you're adding it as it adds no value
Some Git software developers care to keep the information complete
for the author commit.
> to anyone and makes it look like you don't know what you're doing.
I specify message field
Hi Markus,
On Wed, Jul 8, 2015 at 5:09 PM, SF Markus Elfring
wrote:
>> There's a file in the documentation directory of the kernel
>> tree describing submitting patches and email client setup.
>> Read them both,
>
> I read this information several times.
>
>
>> do what they say without anything e
> There's a file in the documentation directory of the kernel
> tree describing submitting patches and email client setup.
> Read them both,
I read this information several times.
> do what they say without anything extra.
Do you see any special consequences if a bit of "extra" functionality
is
Hi Markus,
On Wed, Jul 8, 2015 at 2:15 AM, SF Markus Elfring
wrote:
>> I can't remember ever changing or explicitly preserving the commit date.
>> I don't think I care enough.
>
> Would any more software developers and maintainers like to share
> their experiences around such details?
>
> When do
> I can't remember ever changing or explicitly preserving the commit date.
> I don't think I care enough.
Would any more software developers and maintainers like to share
their experiences around such details?
When do commit timestamps become relevant as a documentation item
for contribution auth
On Tue, Jul 7, 2015 at 1:53 PM, SF Markus Elfring
wrote:
>> I think that as far as these kernel mailing lists are concerned,
>> the date of the update suggestion is the date on which you submitted the
>> patch,
>> rather than the date you originally committed it to your local tree.
>
> I imagine
> I think that as far as these kernel mailing lists are concerned,
> the date of the update suggestion is the date on which you submitted the
> patch,
> rather than the date you originally committed it to your local tree.
I imagine that there are committers who would like to keep
corresponding so
On Tue, Jul 7, 2015 at 9:54 AM, SF Markus Elfring
wrote:
>> No need to try and preserve it.
>
> I find that it might occasionally help to share and keep the record
> on timestamps about the evolution for an original update suggestion.
I think that as far as these kernel mailing lists are concern
> The date, as far as I know, is ignored. It is the commit date,
> not the authoring date, and once your patch is applied by a maintainer
> (i.e. committed), the date gets reset anyway.
Thanks for your feedback.
> No need to try and preserve it.
I find that it might occasionally help to share a
On Tue, Jul 7, 2015 at 8:21 AM, SF Markus Elfring
wrote:
>>> From: Markus Elfring
>>> Date: Sat, 27 Jun 2015 15:56:57 +0200
>>
>> Why is this in the body of the email?
>
> Does the canonical patch format support to preserve
> specific details about a shown commit by specification
> of fields like
>> From: Markus Elfring
>> Date: Sat, 27 Jun 2015 15:56:57 +0200
>
> Why is this in the body of the email?
Does the canonical patch format support to preserve
specific details about a shown commit by specification
of fields like "Date" and "From" in the message body?
Regards,
Markus
___
17 matches
Mail list logo
