From: Phillip Wood
If the user commits or resets a conflict resolution in the middle of a
sequence of cherry-picks or reverts then CHERRY_PICK_HEAD/REVERT_HEAD
will be removed and so in the absence of those files we need to check
.git/sequencer/todo to see if there is a cherry-pick or revert in
p
Fix the detection of in-progress cherry-picks and reverts when the user
commits or resets a conflict resolution in the middle of a sequence of
picks/reverts.
Phillip Wood (1):
git-prompt: improve cherry-pick/revert detection
contrib/completion/git-prompt.sh | 37
When I first tried to use the git-prompt.sh script, I followed the
instructions at the top of the file and everything worked, except for the
"GIT_PS1_SHOWDIRTYSTATE" preference. Even though I had it set to true, I
wasn't seeing the "()" and "(+)" in my shell prompt. After a few hours of
poking arou
/to/repo (BARE:master
This patch fixes the issue by changing the internal field separator
variable IFS to $'\r\n' before using the read builtin command.
Note that ANSI-C Quoting/POSIX Quoting ($'...') is supported by bash
as well as zsh, which are the current targets of git
__git_eread is used to read a single line of a given file (if it exists)
into a single variable stripping the EOL.
This patch removes the unused capability to split file contents into tokens
by passing multiple variable names. Add a comment and explicitly use $2
instead of misleading $@ as argument
Dear Junio,
I'm amazed at how much time and energy you spend on correcting these
essentially non-issues in my git commit messages for a quadruple-liner
code change.
I'll resend both patches one last time addressing the grave issue of the
informative mention of multi-line files.
Regards,
Robert
Robert Abel writes:
> On 05 Dec 2017 01:27, Junio C Hamano wrote:
>> I know all of the above, but I think you misunderstood the point I
>> wanted to raise, so let me try again. The thing is, none of what
>> you just wrote changes the fact that lack of callers that want to do
>> "multi-line" is I
Hi Junio,
On 05 Dec 2017 01:27, Junio C Hamano wrote:
> I know all of the above, but I think you misunderstood the point I
> wanted to raise, so let me try again. The thing is, none of what
> you just wrote changes the fact that lack of callers that want to do
> "multi-line" is IRRELEVANT.
I dis
Robert Abel writes:
> Hi Junio,
>
> On 04 Dec 2017 18:58, Junio C Hamano wrote:
>> Robert Abel writes:
>>> __git_eread is used to read a single line of a given file (if it exists)
>>> into a variable without the EOL. All six current users of __git_eread
>>> use it that way and don't expect multi
__git_eread is used to read a single line of a given file (if it exists)
into a single variable without the EOL. All six current users of __git_eread
use it that way and don't expect multi-line content.
Therefore, this patch removes the unused capability to split file conents into
tokens by passin
If any of the files read by __git_eread have \r\n line endings, read
will only strip \n, leaving \r. This results in an ugly prompt, where
instead of
user@pc MINGW64 /path/to/repo (BARE:master)
the last parenthesis is printed over the beginning of the prompt like
)ser@pc MINGW64 /path/to
Hi Junio,
On 04 Dec 2017 18:58, Junio C Hamano wrote:
> Robert Abel writes:
>> __git_eread is used to read a single line of a given file (if it exists)
>> into a variable without the EOL. All six current users of __git_eread
>> use it that way and don't expect multi-line content.
>
> Changing $@
Robert Abel writes:
> __git_eread is used to read a single line of a given file (if it exists)
> into a variable without the EOL. All six current users of __git_eread
> use it that way and don't expect multi-line content.
Changing $@ to $2 does not change whether this is about "multi-line"
or no
Hi Robert,
1/2 looks very good.
On Sat, 2 Dec 2017, Robert Abel wrote:
> If any of the files read by __git_eread have \r\n line endings, read
> will only strip \n, leaving \r. This results in an ugly prompt, where
> instead of
>
> user@pc MINGW64 /path/to/repo (BARE:master)
>
> the last pa
__git_eread is used to read a single line of a given file (if it exists)
into a variable without the EOL. All six current users of __git_eread
use it that way and don't expect multi-line content.
Thus, add a comment and explicitly use $2 instead of shifting the args
down and using $@.
Signed-off-
If any of the files read by __git_eread have \r\n line endings, read
will only strip \n, leaving \r. This results in an ugly prompt, where
instead of
user@pc MINGW64 /path/to/repo (BARE:master)
the last parenthesis is printed over the beginning of the prompt like
)ser@pc MINGW64 /path/to
Hi Robert,
On Thu, 30 Nov 2017, Robert Abel wrote:
> On 30 Nov 2017 16:21, Johannes Schindelin wrote:
> > On Thu, 30 Nov 2017, Robert Abel wrote:
> >> So reading a dummy variable along with the actual content variable
> >> works for git-prompt
On Thu, Nov 30, 2017 at 2:51 AM, Johannes Schindelin
wrote:
> On Thu, 30 Nov 2017, SZEDER Gábor wrote:
>
>> > > diff --git a/contrib/completion/git-prompt.sh
>> > > b/contrib/completion/git-prompt.sh
>> > > index c6cbef38c2..71a64e7959 100644
>> > > --- a/contrib/completion/git-prompt.sh
>> > > +
Hi Johannes,
On 30 Nov 2017 16:21, Johannes Schindelin wrote:
> On Thu, 30 Nov 2017, Robert Abel wrote:
>> So reading a dummy variable along with the actual content variable
>> works for git-prompt:
>>
>> __git_eread ()
>> {
>> local f="
Hi Robert,
On Thu, 30 Nov 2017, Robert Abel wrote:
> So reading a dummy variable along with the actual content variable
> works for git-prompt:
>
> __git_eread ()
> {
> local f="$1"
> local dummy
> shift
> test -r &quo
|foo:
123 456.|
000d
62 61 72 3a 20|bar: |
0005
Notice the 0d at the end of foo, which didn't get trimmed.
So reading a dummy variable along with the actual content variable
works for git-prompt:
__git_eread ()
{
local f="$1"
local dummy
shift
test -r "$f" && IFS=$'\r\n' read "$@" dummy < "$f"
}
I feel like this would be the most readable solution thus far.
Regards,
Robert
Hi Gábor,
On Thu, 30 Nov 2017, SZEDER Gábor wrote:
> > > diff --git a/contrib/completion/git-prompt.sh
> > > b/contrib/completion/git-prompt.sh
> > > index c6cbef38c2..71a64e7959 100644
> > > --- a/contrib/completion/git-prompt.sh
> > > +++ b/contrib/completion/git-prompt.sh
> > > @@ -282,7 +282
> > diff --git a/contrib/completion/git-prompt.sh
> > b/contrib/completion/git-prompt.sh
> > index c6cbef38c2..71a64e7959 100644
> > --- a/contrib/completion/git-prompt.sh
> > +++ b/contrib/completion/git-prompt.sh
> > @@ -282,7 +282,7 @@ __git_eread ()
> > {
> > local f="$1"
> > shift
>
Hi Robert,
On Wed, 29 Nov 2017, Robert Abel wrote:
> On 29 Nov 2017 15:27, Johannes Schindelin wrote:
>
> > Or maybe keep with the Bash construct, but guarded behind a test that we
> > area actually running in Bash? Something like
> >
> > test -z "$BASH" || IFS=$' \t\r\n'
>
> Actually, this
Hi Johannes,
On 29 Nov 2017 15:27, Johannes Schindelin wrote:
>> diff --git a/contrib/completion/git-prompt.sh
>> b/contrib/completion/git-prompt.sh
>> index c6cbef38c2..71a64e7959 100644
>> --- a/contrib/completion/git-prompt.sh
>> +++ b/contrib/completion/git-prompt.sh
>> @@ -282,7 +282,7 @@ __
Hi Robert,
On Tue, 28 Nov 2017, Robert Abel wrote:
> If any of the files read by __git_eread have \r\n line endings, read
> will only strip \n, leaving \r. This results in an ugly prompt, where
> instead of
>
> user@pc MINGW64 /path/to/repo (BARE:master)
>
> the last parenthesis is printed
If any of the files read by __git_eread have \r\n line endings, read
will only strip \n, leaving \r. This results in an ugly prompt, where
instead of
user@pc MINGW64 /path/to/repo (BARE:master)
the last parenthesis is printed over the beginning of the prompt like
)ser@pc MINGW64 /path/to
I noticed today that my git prompt using msys-git on Windows got a bit broken.
After investigating I found that the git-prompt doesn't handle the case when
__git_eread reads Windows line endings \r\n. It will only strip \n, leaving
the \r.
I noticed this when I created a repository with msy
Junio C Hamano venit, vidit, dixit 15.03.2017 20:25:
> Michael J Gruber writes:
>
>> git-prompt has various describe styles, among them "describe" (by
>> annotated tags) and "default" (by exact match with any tag).
>>
>> Add a mode "tag&quo
Michael J Gruber writes:
> git-prompt has various describe styles, among them "describe" (by
> annotated tags) and "default" (by exact match with any tag).
>
> Add a mode "tag" that describes by any tag, annotated or not.
>
> Signed-off-by: M
git-prompt has various describe styles, among them "describe" (by
annotated tags) and "default" (by exact match with any tag).
Add a mode "tag" that describes by any tag, annotated or not.
Signed-off-by: Michael J Gruber
---
contrib/completion/git-prompt
Simon Oosthoek writes:
> Hi Andrew
>
> sorry, I only noticed your request this morning...
>
> On 22/04/16 07:00, Andrew Schwartzmeyer wrote:
>> diff --git a/contrib/completion/git-prompt.sh
>> b/contrib/completion/git-prompt.sh
>> index f18aedc73..ffe79168c 100644
>> --- a/contrib/completion/git
, you can have colors in
your custom Git prompt function, no problem.
Signed-off-by: Andrew Schwartzmeyer
---
contrib/completion/git-prompt.sh | 12 ++--
1 file changed, 6 insertions(+), 6 deletions(-)
diff --git a/contrib/completion/git-prompt.sh b/contrib/completion/git-prompt.sh
Hi Rudy,
I think the commit subject should include a bit more detail. Ideally,
the subject would start with 'bash prompt: ' to make it clear what
area the commit involves. Then you would want to describe what
inconsistency is being fixed (and why).
Rudy YAYON wrote:
---
contrib/completion
---
contrib/completion/git-prompt.sh | 8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/contrib/completion/git-prompt.sh b/contrib/completion/git-prompt.sh
index 07b52be..18be99f 100644
--- a/contrib/completion/git-prompt.sh
+++ b/contrib/completion/git-prompt.sh
@@ -194,1
Quoting Cody Taylor :
SZEDER Gábor 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 do
SZEDER Gábor 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 case
SZEDER Gábor writes:
> Hi,
>
> Quoting Junio C Hamano :
>
>> Cody A Taylor writes:
>>> 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.
>
> Somehow I had a h
Hi,
Quoting Junio C Hamano :
> Cody A Taylor writes:
>> 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.
Somehow I had a hard time making sense out of "when the
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 b
>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.
The __git_ps1() prompt function would not show an untracked
state when the current work
>From 3e4e22e93bf07355b40ba0abcb3a15c4941cfee7 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.
The __git_ps1() prompt function would not show an untracked
state when the current work
Hi,
Quoting Tony Finch :
Signed-off-by: Tony Finch
---
contrib/completion/git-prompt.sh | 8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/contrib/completion/git-prompt.sh
b/contrib/completion/git-prompt.sh
index 3c3fc6d..3e70e74 100644
--- a/contrib/completion/git-
Signed-off-by: Tony Finch
---
contrib/completion/git-prompt.sh | 8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/contrib/completion/git-prompt.sh b/contrib/completion/git-prompt.sh
index 3c3fc6d..3e70e74 100644
--- a/contrib/completion/git-prompt.sh
+++ b/contrib/complet
SZEDER Gábor wrote:
>
> Makes sense, but the patch doesn't cover all cases, because
> __git_ps1() can exit early
Thanks for looking at the patch. I feel quite silly for missing the other
return points :-( Follow-up patch on the way...
Tony.
--
f.anthony.n.finchhttp://dotat.at/
Faeroes, Sout
Hi,
Quoting Tony Finch :
If you have a prompt which displays the command exit status,
__git_ps1 without this change corrupts it, although it has
the correct value in the parent shell:
~/src/git (master) 0 $ set | grep ^PS1
PS1='\w$(__git_ps1) $? \$ '
~/src/git (master) 0
Junio C Hamano wrote:
>
> Yes. I wouldn't have spent 20 minutes experimenting with various
> hypothetical use cases if the above were there in the first place.
Sorry for wasting your time, and thanks for reviewing the patch.
(I am so used to having $? in my prompt it took me ages to find and
ex
Tony Finch writes:
> If you have a prompt which displays the command exit status,
> __git_ps1 without this change corrupts it, although it has
> the correct value in the parent shell:
>
> ~/src/git (master) 0 $ set | grep ^PS1
> PS1='\w$(__git_ps1) $? \$ '
> ~/src/git (master) 0
If you have a prompt which displays the command exit status,
__git_ps1 without this change corrupts it, although it has
the correct value in the parent shell:
~/src/git (master) 0 $ set | grep ^PS1
PS1='\w$(__git_ps1) $? \$ '
~/src/git (master) 0 $ false
~/src/git (
Tony Finch writes:
> Signed-off-by: Tony Finch
> ---
> contrib/completion/git-prompt.sh | 4
> 1 file changed, 4 insertions(+)
>
> diff --git a/contrib/completion/git-prompt.sh
> b/contrib/completion/git-prompt.sh
> index c5473dc..5fe69d0 100644
> --- a/contrib/completion/git-prompt.sh
>
Signed-off-by: Tony Finch
---
contrib/completion/git-prompt.sh | 4
1 file changed, 4 insertions(+)
diff --git a/contrib/completion/git-prompt.sh b/contrib/completion/git-prompt.sh
index c5473dc..5fe69d0 100644
--- a/contrib/completion/git-prompt.sh
+++ b/contrib/completion/git-prompt.sh
@@
On Sun, Aug 24, 2014 at 08:22:41PM +0700, Gábor Szeder wrote:
> On Aug 23, 2014 12:26 PM, Jeff King wrote:
> > Since dd0b72c (bash prompt: use bash builtins to check stash
> > state, 2011-04-01), git-prompt checks whether we have a
> > stash by looking for $GIT_DIR/
Hi,
On Aug 23, 2014 12:26 PM, Jeff King wrote:
> Since dd0b72c (bash prompt: use bash builtins to check stash
> state, 2011-04-01), git-prompt checks whether we have a
> stash by looking for $GIT_DIR/refs/stash. Generally external
> programs should never do this, because the
Since dd0b72c (bash prompt: use bash builtins to check stash
state, 2011-04-01), git-prompt checks whether we have a
stash by looking for $GIT_DIR/refs/stash. Generally external
programs should never do this, because they would miss
packed-refs.
That commit claims that packed-refs does not pack
SZEDER Gábor writes:
> On Thu, Jun 27, 2013 at 10:31:57PM -0300, Eduardo R. D'Avila wrote:
>> The merged result is ok!
>
> Yeah, it look good, thanks.
Thanks, both, for double checking (and thank you for preparing the
pre-merged results).
--
To unsubscribe from this list: send the line "unsubscr
Hi,
On Thu, Jun 27, 2013 at 10:31:57PM -0300, Eduardo R. D'Avila wrote:
> The merged result is ok!
Yeah, it look good, thanks.
Gábor
--
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.kern
Hi Junio,
The merged result is ok!
Thanks,
Eduardo
--
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
Queued, and merged to 'pu' without the previous merge with the older
iteration. If you two can double check the merged result, it would
be very much appreciated.
Thanks.
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More ma
git-prompt.sh lacks tests for PROMPT_COMMAND mode.
Add tests for:
* pcmode prompt without colors
* pcmode prompt with colors for bash
* pcmode prompt with colors for zsh
Having these tests enables an upcoming refactor in
a safe way.
Signed-off-by: Eduardo R. D'Avila
---
254 0 t/t9903-
'Avila (5):
t9903: add tests for git-prompt pcmode
git-prompt.sh: refactor colored prompt code
t9903: remove redundant tests
git-prompt.sh: do not print duplicate clean color code
git-prompt.sh: add missing information in comments
contrib/completion/git-prompt.sh | 111 +
On Sat, Jun 22, 2013 at 01:32:38PM -0300, Eduardo D'Avila wrote:
> These tests where important to make sure that I wouldn't break anything during
> the refactorization. Having them pass before *and* after refactorization
> guarantees that nothing was broken (except for some subtle case that might
"Eduardo D'Avila" writes:
> However, I agree that they became redundant.
>
> Would it make sense to include a patch that only removes the zsh
> tests, after the refactorization?
I think that would be a sensible thing to do.
In any case, Szeder seems to be giving a good guidance on patches in
th
2013/6/22 SZEDER Gábor :
> On Thu, Jun 20, 2013 at 11:25:26PM -0300, Eduardo R. D'Avila wrote:
>> git-prompt.sh lacks tests for PROMPT_COMMAND mode.
>>
>> Add tests for:
>> * pcmode prompt without colors
>> * pcmode prompt with colors for bash
>> * pcmode prompt with colors for zsh
>>
>> Having the
Hi,
On Thu, Jun 20, 2013 at 11:25:26PM -0300, Eduardo R. D'Avila wrote:
> git-prompt.sh lacks tests for PROMPT_COMMAND mode.
>
> Add tests for:
> * pcmode prompt without colors
> * pcmode prompt with colors for bash
> * pcmode prompt with colors for zsh
>
> Having these tests enables an upcoming
-control.git/228308 .
Some of the patches could still be used, so I'm
reposting them with an additional one to add some
missing information in usage comments.
Eduardo R. D'Avila (4):
t9903: add tests for git-prompt pcmode
git-prompt.sh: refactor colored prompt code
git-prompt.
git-prompt.sh lacks tests for PROMPT_COMMAND mode.
Add tests for:
* pcmode prompt without colors
* pcmode prompt with colors for bash
* pcmode prompt with colors for zsh
Having these tests enables an upcoming refactor in
a safe way.
Signed-off-by: Eduardo R. D'Avila
---
254 0 t/t9903-
git-prompt.sh lacks tests for PROMPT_COMMAND mode.
Add tests for:
* pcmode prompt without colors
* pcmode prompt with colors for bash
* pcmode prompt with colors for zsh
Having these tests enables an upcoming refactor in
a safe way.
Signed-off-by: Eduardo R. D'Avila
---
254 0 t/t9903-
"Eduardo R. D'Avila" writes:
> git-prompt.sh lacks tests for PROMPT_COMMAND mode.
>
> Add tests for:
> * pcmode prompt without colors
> * pcmode prompt with colors for bash
> * pcmode prompt with colors for zsh
>
> Having these tests enables an upcoming refactor in
> a safe way.
>
> Signed-off-by
git-prompt.sh lacks tests for PROMPT_COMMAND mode.
Add tests for:
* pcmode prompt without colors
* pcmode prompt with colors for bash
* pcmode prompt with colors for zsh
Having these tests enables an upcoming refactor in
a safe way.
Signed-off-by: Eduardo R. D'Avila
---
250 0 t/t9903-
On Mon, Feb 11, 2013 at 4:24 AM, Junio C Hamano wrote:
> Jeff King writes:
>
>> On Sun, Feb 10, 2013 at 01:25:38PM -0800, Jonathan Nieder wrote:
>>
>>> Ethan Reesor wrote:
>>>
>>> > I have a git user set up on my server. It's prompt is set to
Jeff King writes:
> On Sun, Feb 10, 2013 at 01:25:38PM -0800, Jonathan Nieder wrote:
>
>> Ethan Reesor wrote:
>>
>> > I have a git user set up on my server. It's prompt is set to
>> > git-prompt and it's git-shell-commands is empty.
>> [.
On Sun, Feb 10, 2013 at 01:25:38PM -0800, Jonathan Nieder wrote:
> Ethan Reesor wrote:
>
> > I have a git user set up on my server. It's prompt is set to
> > git-prompt and it's git-shell-commands is empty.
> [...]
> > How do I make the git user work like git
That would be perfect. (And I did mean I set the login shell to
git-prompt. Additionally, the git user does not have permissions to
run any other shell.) However, when I remove the git-shell-commands
directory I get (on the local end):
fatal: Interactive git shell is not enabled.
hint: ~/git
Ethan Reesor wrote:
> I have a git user set up on my server. It's prompt is set to
> git-prompt and it's git-shell-commands is empty.
[...]
> How do I make the git user work like github where, upon attempting to
> get a prompt, the connection is closed?
I assume you mean
git-svn reads usernames and other user queries from an interactive
terminal. This cause GUIs (w/o STDIN connected) to hang waiting forever
for git-svn to complete
(http://code.google.com/p/tortoisegit/issues/detail?id=967).
This change extends the Git::prompt helper, so that it can also be used
Anders Kaseorg writes:
> GIT_PS1_DESCRIBE_STYLE was introduced in v1.6.3.2~35. Document it in the
> header comments.
>
> Signed-off-by: Anders Kaseorg
> ---
Thanks.
> contrib/completion/git-prompt.sh | 9 +
> 1 file changed, 9 insertions(+)
>
> diff --git a/contrib/completion/git-pr
GIT_PS1_DESCRIBE_STYLE was introduced in v1.6.3.2~35. Document it in the
header comments.
Signed-off-by: Anders Kaseorg
---
contrib/completion/git-prompt.sh | 9 +
1 file changed, 9 insertions(+)
diff --git a/contrib/completion/git-prompt.sh b/contrib/completion/git-prompt.sh
index bf
git-svn reads usernames and other user queries from an interactive
terminal. This cause GUIs (w/o STDIN connected) to hang waiting forever
for git-svn to complete
(http://code.google.com/p/tortoisegit/issues/detail?id=967).
This change extends the Git::prompt helper, so that it can also be used
Sven Strickroth writes:
> Am 04.01.2012 01:12 schrieb Junio C Hamano:
>> Now "prompt" is no longer a method but is merely a helper function, so
>> I've queued this (and 1/2 rewrite we discussed in a separate thread) to
>> 'pu' after rewording the commit log message.
>>
>> Thanks.
>
> Is there a
Am 04.01.2012 01:12 schrieb Junio C Hamano:
> Now "prompt" is no longer a method but is merely a helper function, so
> I've queued this (and 1/2 rewrite we discussed in a separate thread) to
> 'pu' after rewording the commit log message.
>
> Thanks.
Is there a reason why these changes did not get
80 matches
Mail list logo
