# [Documentation] Submitting Patches 2 messages from 2015-03-13 to 2015-03-13. Participants: Cody Taylor, Junio C Hamano. Thread: https://gitlist.dev/t/38792 ## Cody Taylor, 2015-03-13 06:31 Subject: [Documentation] Submitting Patches Message-ID: URL: https://gitlist.dev/e/CAHWMk2YuUvYYb-nxdANVxZ0tLsyttnqNzpF74Nxz1zpFcGEnGg%40mail.gmail.com ``` Apologies for the poorly formatted e-mail. I realized after I sent the message that the `git send-mail` command was an option. I was trying to use python to modify the e-mail before sending it, and the three different "From" fields got mumbled. Anyway, this brings up the point that `git send-email` should at least get a mention in the "Documentation/SubmittingPatches" file. Likely the best place for this is a paragraph after `git format-patch` is mentioned in section 4 ("Sending your patches."). On Fri, Mar 13, 2015 at 2:16 AM, Junio C Hamano wrote: > > Cody A Taylor writes: > > > From c861d5cb401110ce7d86b76c1eaa8e89e80f484e Mon Sep 17 00:00:00 2001 > > From: Cody A Taylor > > Date: Thu, 12 Mar 2015 20:36:44 -0400 > > Subject: [PATCH] git prompt: Use toplevel to find untracked files. > > All of the above four lines are unwanted in the e-mail body. > > * The first line is a separating line to make format-patch output > look like a mbox file, and does not even belong to this patch. > > * From: line, when you are not relaying somebody else's patch, > should not be necessary, as long as you set up your MUA correctly > so that the e-mail shows a correct From: in its header. > > * Date: is the same; unless you are relaying somebody else's patch, > in which case you might want to preserve the author timestamp, > the first time _we_ the recipients see your patch matters more, > which should be available from the e-mail header. > > * Subject: should be in the e-mail header. Sometimes when sending > a patch to an ongoing discussion that has its own subject, it is > handy to be able to override the title with in-body Subject:, but > this patch submission is not such a case. The subjects are the > same in the fourth line in the body (which should be dropped) and > in the header anyway in this message, so please edit it out. > > In short > > (1) If you cannot convince your mailer to show your @yahoo.com > address on the e-mail header From: line, then having the > in-body From: line above (i.e. the second line) is OK as a > workaround. We however would prefer if you didn't. > > (2) Edit the other three lines out. > > > The __git_ps1() prompt function would not show an untracked > > state when the current working directory was not a parent of > > the untracked file. > > Good find, and nicely explained. I wonder if we can add a test > or two to t9903-bash-prompt.sh? > > The patch itself makes sense. Thanks. > > > Signed-off-by: Cody A Taylor > > --- > > contrib/completion/git-prompt.sh | 2 +- > > 1 file changed, 1 insertion(+), 1 deletion(-) > > > > diff --git a/contrib/completion/git-prompt.sh b/contrib/completion/git-prompt.sh > > index 214e859f99e7..f18aedc73be9 100644 > > --- a/contrib/completion/git-prompt.sh > > +++ b/contrib/completion/git-prompt.sh > > @@ -487,7 +487,7 @@ __git_ps1 () > > > > if [ -n "${GIT_PS1_SHOWUNTRACKEDFILES-}" ] && > > [ "$(git config --bool bash.showUntrackedFiles)" != "false" ] && > > - git ls-files --others --exclude-standard --error-unmatch -- '*' >/dev/null 2>/dev/null > > + git ls-files --others --exclude-standard --error-unmatch -- ':/*' >/dev/null 2>/dev/null > > then > > u="%${ZSH_VERSION+%}" > > fi ``` ## Junio C Hamano, 2015-03-13 07:02 Subject: Re: [Documentation] Submitting Patches Message-ID: URL: https://gitlist.dev/e/xmqqa8zhz8g8.fsf%40gitster.dls.corp.google.com In-Reply-To: ``` Cody Taylor writes: > Anyway, this brings up the point that `git send-email` should at least > get a mention in the "Documentation/SubmittingPatches" file. Likely > the best place for this is a paragraph after `git format-patch` is > mentioned in section 4 ("Sending your patches."). [removed others who are not to be blamed for the lack of doc from cc] I very much agree with that---actually I am somewhat surprised that the documentation doesn't do so already. Perhaps something like this? -- >8 -- Subject: SubmittingPatches: nudge to use send-email In step "(4) Sending your patches", we instruct users to do an inline patch, avoid breaking whitespaces, avoid attachments, use [PATCH v2] for second round, etc., all of which send-email knows how to do. Mention send-email at least once to gently nudge the user to (learn to) use it. Suggested-by: Cody Taylor Signed-off-by: Junio C Hamano --- Documentation/SubmittingPatches | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/Documentation/SubmittingPatches b/Documentation/SubmittingPatches index ef0eeb4..2b10569 100644 --- a/Documentation/SubmittingPatches +++ b/Documentation/SubmittingPatches @@ -154,7 +154,8 @@ you send off a message in the correct encoding. WARNING: Be wary of your MUAs word-wrap corrupting your patch. Do not cut-n-paste your patch; you can -lose tabs that way if you are not careful. +lose tabs that way if you are not careful. If you can use the +"git send-email" command, please do so. It is a common convention to prefix your subject line with [PATCH]. This lets people easily distinguish patches from other ```