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

SF Markus Elfring
2015-07-08T09:28:44Z

> 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 overrides in my update suggestions intentionally.

> The issue is that the headers you're adding, From: and Date: are unnecessary.

We have got different opinions about the purpose.

> The From: header you add is unnecessary as your email's From: header
> has the exact same information.

I would like to point out that there is a slight difference in my use case.

> The reason it's there is because sometimes people forward patches on
> from other people, e.g. if I were to resend one of your patches,
> I'd add a From: header to the body of the email so it'd be credited to you.

I am also interested in such an use case.

> The Date: header you add is unnecessary as git-format-patch sets the
> date header in the email it produces to the author date stored in the commit.

How do you think about my extra patch preparation for the mentioned
mail forwarding?

> So if you're sending your patches in emails produced by git-format-patch,
> there's absolutely no reason to include it.

I disagree here to some degree.

The difference in suggested commit timestamps of a few minutes might look
negligible for some patches. There are few occasions where the delay between
a concrete commit and its publishing by an interface like email
can become days.

> They are both almost completely irrelevant for most workflows as people
> are less interested in when a commit was made and more interested in what
> release it's in, how it was merged, etc. All of which should be
> determined without using the timestamp.

How often will it matter who made and published a change first?

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

> How would you feel if someone came in to your place of work
> and told you to change how you do the job you've been doing for years
> without a good reason?

You might feel uncomfortable for a moment if you would interpret
such a suggestion as a personal attack.

I guess that I point only a few technical details out which can change
the popularity of existing functionality from the Git software.

Regards,
Markus