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.
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
> 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
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
> 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
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
> 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
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
> 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
Hi Markus,
On Wed, Jul 8, 2015 at 7:28 PM, SF Markus Elfring
elfr...@users.sourceforge.net 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
Hi Markus,
On Wed, Jul 8, 2015 at 5:09 PM, SF Markus Elfring
elfr...@users.sourceforge.net 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
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
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 of
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
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 reuse
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 11:46 PM, SF Markus Elfring
elfr...@users.sourceforge.net 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
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
> 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
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
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
> 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
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
>> 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
--
To
From: Markus Elfring elfr...@users.sourceforge.net
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?
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
On Tue, Jul 7, 2015 at 9:54 AM, SF Markus Elfring
elfr...@users.sourceforge.net 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
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 and
On Tue, Jul 7, 2015 at 8:21 AM, SF Markus Elfring
elfr...@users.sourceforge.net wrote:
From: Markus Elfring elfr...@users.sourceforge.net
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
Hi Markus,
On Wed, Jul 8, 2015 at 2:15 AM, SF Markus Elfring
elfr...@users.sourceforge.net 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
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
On Tue, Jul 7, 2015 at 1:53 PM, SF Markus Elfring
elfr...@users.sourceforge.net 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
34 matches
Mail list logo
