From: Felipe Contreras <hidden> Date: 2021-06-06 18:48:36
These should be pretty obvious and straightforward.
This is the second time I'm sending this exact series, and the seventh time in almost
exactly the same form.
The previous version was still applying without conflicts to master, and so does this one.
* https://lore.kernel.org/git/xmqqv9cavcc5.fsf@gitster.c.googlers.com/
* https://lore.kernel.org/git/6094a335c22dc_8ee520860@natae.notmuch/
Felipe Contreras (4):
completion: bash: fix prefix detection in branch.*
completion: bash: fix for suboptions with value
completion: bash: fix for multiple dash commands
completion: bash: add correct suffix in variables
contrib/completion/git-completion.bash | 14 +++++++-------
t/t9902-completion.sh | 15 +++++++++++++++
2 files changed, 22 insertions(+), 7 deletions(-)
Range-diff:
1: dd49b0e680 ! 1: 52de92cb06 completion: bash: fix prefix detection in branch.*
@@ Commit message
git clone --config=branch.<tab>
+ Reviewed-by: SZEDER Gábor [off-list ref]
Signed-off-by: Felipe Contreras [off-list ref]
## contrib/completion/git-completion.bash ##
2: 6ac184b9a4 = 2: af2f17364d completion: bash: fix for suboptions with value
3: 960a692fda = 3: a3bcb70594 completion: bash: fix for multiple dash commands
4: a95c3edaf9 = 4: 6b3ef41c92 completion: bash: add correct suffix in variables
--
2.31.1.2.g0532ba4bf6
From: Felipe Contreras <hidden> Date: 2021-06-06 18:47:45
We need to ignore options that don't start with -- as well.
Depending on the value of COMP_WORDBREAKS the last word could be
duplicated otherwise.
Can be tested with:
git merge -X diff-algorithm=<tab>
Signed-off-by: Felipe Contreras <redacted>
---
contrib/completion/git-completion.bash | 2 +-
t/t9902-completion.sh | 15 +++++++++++++++
2 files changed, 16 insertions(+), 1 deletion(-)
From: Felipe Contreras <hidden> Date: 2021-06-06 18:48:53
Otherwise we are completely ignoring the --cur argument.
The issue can be tested with:
git clone --config=branch.<tab>
Reviewed-by: SZEDER Gábor <redacted>
Signed-off-by: Felipe Contreras <redacted>
---
contrib/completion/git-completion.bash | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
From: Felipe Contreras <hidden> Date: 2021-06-06 18:49:01
__gitcomp automatically adds a suffix, but __gitcomp_nl and others
don't, we need to specify a space by default.
Can be tested with:
git config branch.autoSetupMe<tab>
This fix only works for versions of bash greater than 4.0, before that
"local sfx" creates an empty string, therefore the unset expansion
doesn't work. The same happens in zsh.
Therefore we don't add the test for that for now.
The correct fix for all shells requires semantic changes in __gitcomp,
but that can be done later.
Cc: SZEDER Gábor <redacted>
Signed-off-by: Felipe Contreras <redacted>
---
contrib/completion/git-completion.bash | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
From: David Aguilar <hidden> Date: 2021-06-07 00:47:57
On Sun, Jun 6, 2021 at 11:51 AM Felipe Contreras
[off-list ref] wrote:
These should be pretty obvious and straightforward.
This is the second time I'm sending this exact series, and the seventh time in almost
exactly the same form.
The previous version was still applying without conflicts to master, and so does this one.
* https://lore.kernel.org/git/xmqqv9cavcc5.fsf@gitster.c.googlers.com/
* https://lore.kernel.org/git/6094a335c22dc_8ee520860@natae.notmuch/
Felipe Contreras (4):
completion: bash: fix prefix detection in branch.*
completion: bash: fix for suboptions with value
completion: bash: fix for multiple dash commands
completion: bash: add correct suffix in variables
contrib/completion/git-completion.bash | 14 +++++++-------
t/t9902-completion.sh | 15 +++++++++++++++
2 files changed, 22 insertions(+), 7 deletions(-)
Range-diff:
1: dd49b0e680 ! 1: 52de92cb06 completion: bash: fix prefix detection in branch.*
@@ Commit message
git clone --config=branch.<tab>
+ Reviewed-by: SZEDER Gábor [off-list ref]
Signed-off-by: Felipe Contreras [off-list ref]
## contrib/completion/git-completion.bash ##
2: 6ac184b9a4 = 2: af2f17364d completion: bash: fix for suboptions with value
3: 960a692fda = 3: a3bcb70594 completion: bash: fix for multiple dash commands
4: a95c3edaf9 = 4: 6b3ef41c92 completion: bash: add correct suffix in variables
--
2.31.1.2.g0532ba4bf6
I tested this series on:
- GNU bash, version 4.2.46(2)-release (x86_64-redhat-linux-gnu)
- GNU bash, version 3.2.57(1)-release (x86_64-apple-darwin19)
- zsh 5.0.2 (x86_64-redhat-linux-gnu)
- zsh 5.7.1 (x86_64-apple-darwin19.0)
and can confirm that it is an improvement.
FWIW,
Tested-by: David Aguilar <redacted>
cheers,
--
David
From: SZEDER Gábor <hidden> Date: 2021-06-07 19:01:51
On Sun, Jun 06, 2021 at 01:47:25PM -0500, Felipe Contreras wrote:
Otherwise commands like 'for-each-ref' are not completed.
I think you meant that options of commands like 'for-each-ref' are not
completed. The command itself can be completed just fine:
$ git for<TAB>
for-each-ref format-patch
From: Felipe Contreras <hidden> Date: 2021-06-07 19:12:04
SZEDER Gábor wrote:
On Sun, Jun 06, 2021 at 01:47:25PM -0500, Felipe Contreras wrote:
quoted
Otherwise commands like 'for-each-ref' are not completed.
I think you meant that options of commands like 'for-each-ref' are not
completed. The command itself can be completed just fine:
$ git for<TAB>
for-each-ref format-patch
Yes, I meant commands like 'for-each-ref' are not completed correctly...
by __gitcomp_builtin. Which in practical tearms means what you just
described above.
--
Felipe Contreras
From: Junio C Hamano <hidden> Date: 2021-06-08 05:15:08
Felipe Contreras [off-list ref] writes:
SZEDER Gábor wrote:
quoted
On Sun, Jun 06, 2021 at 01:47:25PM -0500, Felipe Contreras wrote:
quoted
Otherwise commands like 'for-each-ref' are not completed.
I think you meant that options of commands like 'for-each-ref' are not
completed.
...
Yes, I meant commands like 'for-each-ref' are not completed correctly...
by __gitcomp_builtin. Which in practical tearms means what you just
described above.
I couldn't exactly tell if that's a roundabout way to say "yes,
yours is better and I'll use it in an update, thanks". I'll assume
that is the case and will mark the topic as expecting the final
update (as it seemed that all the other patches in the series were
received favourably).
Or was it meant as "no, the version you commented on was already
correct (if you squint your eyes)"?
Thanks.
From: Felipe Contreras <hidden> Date: 2021-06-08 05:50:09
Junio C Hamano wrote:
Felipe Contreras [off-list ref] writes:
quoted
SZEDER Gábor wrote:
quoted
On Sun, Jun 06, 2021 at 01:47:25PM -0500, Felipe Contreras wrote:
quoted
Otherwise commands like 'for-each-ref' are not completed.
I think you meant that options of commands like 'for-each-ref' are not
completed.
...
quoted
Yes, I meant commands like 'for-each-ref' are not completed correctly...
by __gitcomp_builtin. Which in practical tearms means what you just
described above.
I couldn't exactly tell if that's a roundabout way to say "yes,
yours is better and I'll use it in an update, thanks".
I meant that I meant what he said I meant.
But meaning is not saying, and it's better to say what one means
(implied), and since Szeder's version says what I meant, that's better.
I'll assume that is the case and will mark the topic as expecting the
final update (as it seemed that all the other patches in the series
were received favourably).
I think it would be trivial to do s/commands/options of &/ when merging
the series, but fine, I'll reroll.
Or was it meant as "no, the version you commented on was already
correct (if you squint your eyes)"?
From: Felipe Contreras <hidden> Date: 2021-06-08 06:00:28
We need to ignore options that don't start with -- as well.
Depending on the value of COMP_WORDBREAKS the last word could be
duplicated otherwise.
Can be tested with:
git merge -X diff-algorithm=<tab>
Tested-by: David Aguilar <redacted>
Signed-off-by: Felipe Contreras <redacted>
---
contrib/completion/git-completion.bash | 2 +-
t/t9902-completion.sh | 15 +++++++++++++++
2 files changed, 16 insertions(+), 1 deletion(-)
From: Felipe Contreras <hidden> Date: 2021-06-08 06:00:46
Otherwise options of commands like 'for-each-ref' are not completed.
Tested-by: David Aguilar <redacted>
Signed-off-by: Felipe Contreras <redacted>
---
contrib/completion/git-completion.bash | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
From: Felipe Contreras <hidden> Date: 2021-06-08 06:01:22
Otherwise we are completely ignoring the --cur argument.
The issue can be tested with:
git clone --config=branch.<tab>
Reviewed-by: SZEDER Gábor <redacted>
Tested-by: David Aguilar <redacted>
Signed-off-by: Felipe Contreras <redacted>
---
contrib/completion/git-completion.bash | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
From: Felipe Contreras <hidden> Date: 2021-06-08 06:01:30
__gitcomp automatically adds a suffix, but __gitcomp_nl and others
don't, we need to specify a space by default.
Can be tested with:
git config branch.autoSetupMe<tab>
This fix only works for versions of bash greater than 4.0, before that
"local sfx" creates an empty string, therefore the unset expansion
doesn't work. The same happens in zsh.
Therefore we don't add the test for that for now.
The correct fix for all shells requires semantic changes in __gitcomp,
but that can be done later.
Cc: SZEDER Gábor <redacted>
Tested-by: David Aguilar <redacted>
Signed-off-by: Felipe Contreras <redacted>
---
contrib/completion/git-completion.bash | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)