Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.kernel > #1178697 > unrolled thread

Re: Clarification for the use of additional fields in the message body

Back to article view | Back to linux.kernel

This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by below is the oldest one visible, not the original post.

Contents

  Re: Clarification for the use of additional fields in the message  body SF Markus Elfring <elfring@users.sourceforge.net> - 2015-07-07 18:20 +0200
    Re: Clarification for the use of additional fields in the message body Julian Calaby <julian.calaby@gmail.com> - 2015-07-08 01:50 +0200
      Re: Clarification for the use of additional fields in the message  body SF Markus Elfring <elfring@users.sourceforge.net> - 2015-07-08 15:50 +0200
        Re: Clarification for the use of additional fields in the message body Julian Calaby <julian.calaby@gmail.com> - 2015-07-09 01:50 +0200

#1178697 — Re: Clarification for the use of additional fields 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 authorship?


> Remembering the author separately from the committer is something
> git does by design anyway.

Do you usually just reuse a procedure from a well-known command
for which a description is provided like the following?
http://git-scm.com/docs/git-am
'…
"From: " and "Subject: " lines starting the body override
the respective commit author name and title values
taken from the headers.
…'

Will further fields be eventually mentioned there?

Regards,
Markus
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [next] | [standalone]

#1179164 — Re: Clarification for the use of additional fields in the message body

Hi Markus,

On Wed, Jul 8, 2015 at 2:15 AM, SF Markus Elfring
<elfring@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 such details?
>
> When do commit timestamps become relevant as a documentation item
> for contribution authorship?

They are never relevant.

"When" a commit happened is never relevant except in relation to other
things, at which point the actual date and time is almost completely
irrelevant.

Just submit your patches using git-format-patch or git-send-email and
friends. There's a file in the documentation directory of the kernel
tree describing submitting patches and email client setup. Read them
both, do what they say without anything extra.

>> Remembering the author separately from the committer is something
>> git does by design anyway.
>
> Do you usually just reuse a procedure from a well-known command
> for which a description is provided like the following?
> http://git-scm.com/docs/git-am
> '…
> "From: " and "Subject: " lines starting the body override
> the respective commit author name and title values
> taken from the headers.
> …'
>
> Will further fields be eventually mentioned there?

Why? Just do what is described in SubmittingPatches. Your attempts to
"improve" on the system are unnecessary and annoying people. The
instructions there are the recommended way to do things for a reason.

Thanks,

-- 
Julian Calaby

Email: julian.calaby@gmail.com
Profile: http://www.google.com/profiles/julian.calaby/
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [prev] | [next] | [standalone]

#1179845

> 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 patches.


> if you're not, then you're making things overly complicated for yourself.

But I prefer a graphical user interface for my mail handling so far.


> Having a feature doesn't mean that it should be used.

Does any of the "questionable functionality" get occasionally overlooked
a bit too often?

Regards,
Markus
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [prev] | [next] | [standalone]

#1180305 — Re: Clarification for the use of additional fields in the message body

Hi Markus,

On Wed, Jul 8, 2015 at 11:46 PM, SF Markus Elfring
<elfring@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 software development, most people's processes are:

1. Make changes
2. git add <files>
3. git commit
4. Repeat 1-3 for all changes they want to make
5. git-format-patch
6. git-send-email through some SMTP server to the list and appropriate
other people

From what I've read, you appear to have some semi-automatic tool for
steps 1 through 4. I'd strongly recommend changing your patch
submission process to use git-format-patch and git-send-email. If
Sourceforge's email system doesn't let you send emails with SMTP
directly, then you might want to try sending emails through your ISP's
mail server.

Maintainers use a very similar process, however they collect and
review patches in some personal repository in addition to making
changes and committing them. Tools like patchwork are simply fancy
methods of accumulating patches into git trees. Most people are using
git-format-patch and git-send-email, possibly with some scripting
around them, to format and send patches.

>> 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 patches.

git-send-email or some other tool?

>> if you're not, then you're making things overly complicated for yourself.
>
> But I prefer a graphical user interface for my mail handling so far.

I send my patches using git-send-email through gmail's servers then
deal with literally everything else through gmail's web interface or
Android app. Using git-send-email doesn't mean you can't use a
graphical mail interface.

I used to send patches through a carefully configured instance of
Thunderbird, however this required too many steps and it loved to
mangle patches in ways that annoyed people.

>> Having a feature doesn't mean that it should be used.
>
> Does any of the "questionable functionality" get occasionally overlooked
> a bit too often?

It's not "questionable functionality", it's functionality we don't see
a need for.

If I wanted to, I could insert a patch at any point in the history of
Linux in my own repository, however any attempt to push that upstream
would cause enormous amounts of pain and annoyance, to everyone who
attempted to deal with it, so I don't.

Thanks,

-- 
Julian Calaby

Email: julian.calaby@gmail.com
Profile: http://www.google.com/profiles/julian.calaby/
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [prev] | [standalone]

Back to top | Article view | linux.kernel

csiph-web