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 <gitster@xxxxxxxxx> wrote:
>
> Cody A Taylor <cody.taylor@xxxxxxxxxxxxxxxxxxxxxxxxx> writes:
>
> > From c861d5cb401110ce7d86b76c1eaa8e89e80f484e Mon Sep 17 00:00:00 2001
> > From: Cody A Taylor <codemister99@xxxxxxxxx>
> > 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 <codemister99@xxxxxxxxx>
> > ---
> > 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
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html