Re: [PATCH v2] git prompt: Use toplevel to find untracked files.
SZEDER Gábor sze...@ira.uka.de writes: Somehow I had a hard time making sense out of when the current working directory was not a parent of the untracked file. Perhaps when the untracked files are outside of the current working directory would be easier to grok? That description doesn't cover all cases. Scenario #1: Let's say there is an untracked file at `$ROOT/file`. When your CWD is `$ROOT/`, all is well. If you cd to `$ROOT/src/` the ls-files command failed to find the untracked file. Scenario #2: Let's say there is an untracked file at `$ROOT/src/file`. The ls-files command would find the file if the CWD is `$ROOT/` or `$ROOT/src/`, but not if the CWD is `$ROOT/bin/` or `$ROOT/src/folder/`. Your description may be easier to understand, but I don't agree it's accurate. -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[Documentation] Submitting Patches
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 gits...@pobox.com wrote:
Cody A Taylor cody.tay...@maternityneighborhood.com writes:
From c861d5cb401110ce7d86b76c1eaa8e89e80f484e Mon Sep 17 00:00:00 2001
From: Cody A Taylor codemiste...@yahoo.com
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 codemiste...@yahoo.com
---
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 majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [Documentation/RFC] Submitting Patches
Junio C Hamano gits...@pobox.com wrote: 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. The idea that `git send-email` does all of the suggestions really should be reflected in the documentation. Mention send-email at least once to gently nudge the user to (learn to) use it. If the tool is good, do not tippy toe around the subject. Write plain text e-mail is a strange enough experience today, the documentation should plainly state that git send-email is likely the easiest solution to sending a patch or series of patches. Suggesting: Cody A Taylor cody.tay...@maternityneighborhood.com --- Documentation/SubmittingPatches | 8 1 file changed, 8 insertions(+) diff --git a/Documentation/SubmittingPatches b/Documentation/SubmittingPatches index ef0eeb40cd22..702f1ace08ae 100644 --- a/Documentation/SubmittingPatches +++ b/Documentation/SubmittingPatches @@ -136,6 +136,14 @@ that is fine, but please mark it as such. (4) Sending your patches. +The git format-patch and git send-email commands are +complemtary to one another. They are optimized to make the work +flow of sending patches much easier. Primarily, using these +commands avoids the need to re-learn your existing e-mail client +that is optimized for multipart/* mime type e-mails. Using +these tools you will midigate the simple problems that cause poorly +formatted e-mails. + People on the Git mailing list need to be able to read and comment on the changes you are submitting. It is important for a developer to be able to quote your changes, using standard -- v2.3.2 -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[no subject]
From 3e4e22e93bf07355b40ba0abcb3a15c4941cfee7 Mon Sep 17 00:00:00 2001
From: Cody A Taylor codemiste...@yahoo.com
Date: Thu, 12 Mar 2015 20:36:44 -0400
Subject: [PATCH] git prompt: Use toplevel to find untracked files.
The __git_ps1() prompt function would not show an untracked
state when the current working directory was not a parent of
the untracked file.
Signed-off-by: Cody A Taylor codemiste...@yahoo.com
---
contrib/completion/git-prompt.sh | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/contrib/completion/git-prompt.sh b/contrib/completion/git-prompt.sh
index 214e859f99e7..f0d8a2669236 100644
--- a/contrib/completion/git-prompt.sh
+++ b/contrib/completion/git-prompt.sh
@@ -487,7 +487,8 @@ __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 -- \
+$(git rev-parse --show-toplevel)/* /dev/null 2/dev/null
then
u=%${ZSH_VERSION+%}
fi
--
2.3.2
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
