Re: Clarification for the use of additional fields in the message body
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. Thanks for your hint. I am just trying to offer the possibility for the reuse of a more precise commit timestamp together with an appropriate author mail address for my update suggestions. Do you reject any more such message field overrides? Well, I won't hold it against you, since I also often need to fix patches or git commit descriptions anyway. But at the same time, my workflow (which you have no right to dictate) **will** destroy your timestamp. Given that you haven't explained why you want to do this, I'm not going have much sympathy if you complain. Personally, given that you're going through some extremely baroque e-mail/patchsubmission scheme, I don't understand why you can't also arrange to override the Date field in the e-mail header. But I don't really care all that much, because I can ignore your timestamp no matter where you put it. Regards, - Ted ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: Clarification for the use of additional fields in the message body
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 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. Let me rephrase that: they _should_ be unnecessary. 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. Then fix your email client or patch submission process. 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. This happens automatically if you use git-format-patch on a commit you didn't author. Nobody is adding this manually. 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? It sounds like you're using what could only be described as a Rube-Goldberg process to send email. Is there truly no way to simplify that process? (Also, are the servers you send it through re-writing the original headers?) You should be sending the patches directly with SMTP using git-send-email, if you're not, then you're making things overly complicated for yourself. 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. I made a commit a month ago, it got rebased today, in fact, I sent it's metadata in my previous email. When I ran git-format-patch on it, the timestamp in the headers of the email produced was the date from a month ago. If I then sent that email, I believe it'd make it to the list here with that date intact. If it hadn't, I'd be trying to figure out why and either fix it or find a different path to get my patch here. 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? 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. 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. 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'm not interpreting this 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. Git was originally written to manage the Linux kernel. This feature was probably added by either Linus himself or one of the original developers who I believe were kernel developers. The patch submission process has been around for a long time, if this feature isn't used, it's for a good reason. Having a feature doesn't mean that it should be used. Thanks, -- Julian Calaby Email: julian.cal...@gmail.com Profile: http://www.google.com/profiles/julian.calaby/ ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: Clarification for the use of additional fields in the message body
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 ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: Clarification for the use of additional fields in the message body
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 ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: Clarification for the use of additional fields in the message body
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 of a more precise commit timestamp together with an appropriate author mail address for my update suggestions. Do you reject any more such message field overrides? Regards, Markus ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: Clarification for the use of additional fields in the message body
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 ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: Clarification for the use of additional fields in the message body
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 without anything extra. Do you see any special consequences if a bit of extra functionality is already provided by the Git software for a while? If it's harmless, then no, but in this case, people are questioning why you're adding it as it adds no value to anyone and makes it look like you don't know what you're doing. Your attempts to improve on the system are unnecessary It seems that my approach does not need improvements for the current command git am. Would a few extensions for the available documentation help to clarify the situation? The issue is that the headers you're adding, From: and Date: are unnecessary. The From: header you add is unnecessary as your email's From: header has the exact same information. 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. 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. (see below) So if you're sending your patches in emails produced by git-format-patch, there's absolutely no reason to include it. Do items like commit mail address and commit timestamp belong together for the data structure author by design in this content management system? The information stored for a commit is: = = = = = = tree 09496defc9eb793c665a7b80aa22f24c7bd5f204 parent 63c07589832bfe5ec49f2523ddb0e94a20af0f31 author Julian Calaby julian.cal...@gmail.com 1435196810 +1000 committer Julian Calaby julian.cal...@gmail.com 1436322540 +1000 = = = = = = Then the subject and commit message. The numbers after the email addresses are the timestamps. 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. 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. In short, nobody cares, and nobody's going to be upset if the actual time you authored a patch is different to the time recorded upstream. and annoying people. I understand that various update suggestions can be surprising. It is also usual that corresponding acceptance might take a bit longer than what some contributors would prefer. 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? Thanks, -- Julian Calaby Email: julian.cal...@gmail.com Profile: http://www.google.com/profiles/julian.calaby/ ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: Clarification for the use of additional fields in the message body
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 already provided by the Git software for a while? Your attempts to improve on the system are unnecessary It seems that my approach does not need improvements for the current command git am. Would a few extensions for the available documentation help to clarify the situation? Do items like commit mail address and commit timestamp belong together for the data structure author by design in this content management system? and annoying people. I understand that various update suggestions can be surprising. It is also usual that corresponding acceptance might take a bit longer than what some contributors would prefer. Regards, Markus ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
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 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 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.cal...@gmail.com Profile: http://www.google.com/profiles/julian.calaby/ ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: Clarification for the use of additional fields in the message body
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? Regards, Markus ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
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 ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: Clarification for the use of additional fields in the message body
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 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. If you wish to keep track of this evolution for yourself, or wish to share it, you're better off stashing it somewhere in a (public) git repo that you control. If you wish, you can always make mention of that repo below the ---, just above the diffstat. If you insist on placing the date somewhere, you can also put the date there if you wish. It'll be ignored by git when applied. Cheers, Frans ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: Clarification for the use of additional fields in the message body
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 shown commit by specification of fields like Date and From in the message body? Using From: in the body can be used to provide your properly spelled name, or the name/e-mail of the actual author, if that happens not to be the sender. git-send-email will do that automagically for you. If From: is not specified in the message body, the e-mails sender will be used as author. 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. No need to try and preserve it. Frans ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: Clarification for the use of additional fields in the message body
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 keep the record on timestamps about the evolution for an original update suggestion. Regards, Markus ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
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 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 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.cal...@gmail.com Profile: http://www.google.com/profiles/julian.calaby/ ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: Clarification for the use of additional fields in the message body
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 software development history a bit more accurate. If you wish to keep track of this evolution for yourself, or wish to share it, you're better off stashing it somewhere in a (public) git repo that you control. Would it be nicer to preserve such data directly also by the usual mail interface? If you insist on placing the date somewhere, you can also put the date there if you wish. It'll be ignored by git when applied. This content management tool provides the capability to store the discussed information by the parameters --author= and --date=, doesn't it? Is the environment variable GIT_AUTHOR_DATE also interesting occasionally? How often do you take extra care for passing appropriate data there? Regards, Markus ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: Clarification for the use of additional fields in the message body
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 local tree. I imagine that there are committers who would like to keep corresponding software development history a bit more accurate. I guess it depends on what your view on accurate is. If you wish to keep track of this evolution for yourself, or wish to share it, you're better off stashing it somewhere in a (public) git repo that you control. Would it be nicer to preserve such data directly also by the usual mail interface? If you insist on placing the date somewhere, you can also put the date there if you wish. It'll be ignored by git when applied. This content management tool provides the capability to store the discussed information by the parameters --author= and --date=, doesn't it? Is the environment variable GIT_AUTHOR_DATE also interesting occasionally? How often do you take extra care for passing appropriate data there? I can't remember ever changing or explicitly preserving the commit date. I don't think I care enough. I did change the author on botched patches, but that's an exception. Remembering the author separately from the committer is something git does by design anyway. Frans ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
