* Bug in git tab completion: If git.showSignature = true is set globally, tab completion of commits is garbled
@ 2019-03-07 19:23 Adrian Vollmer
2019-03-07 23:27 ` dana
0 siblings, 1 reply; 7+ messages in thread
From: Adrian Vollmer @ 2019-03-07 19:23 UTC (permalink / raw)
To: zsh-workers
Hi,
to reproduce this bug, set showSignature = true in the log section of
your global git config file, then type git reset <TAB> in a git repo
that has a recent signed commit in its history.
It looks like this:
README überarbeitet (23 hours ago) -- [README überarbeitet (23 hours ago)] gpg: Signatu
gpg -- issuer "<censored>":[g
Primary key fingerprint -- XXXX XXXX XXXX XXXX XXXX XXXX XXXX XXXX XXXX 2F
7ded199 -- [7ded199]
92fdb4d -- [92fdb4d] gpg: using RSA key XXXXX
gpg -- Good signature from "<censored>
92fdb4d -- [92fdb4d] formatting (2 days ago)
Cheers,
Adrian
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: Bug in git tab completion: If git.showSignature = true is set globally, tab completion of commits is garbled
2019-03-07 19:23 Bug in git tab completion: If git.showSignature = true is set globally, tab completion of commits is garbled Adrian Vollmer
@ 2019-03-07 23:27 ` dana
2019-03-08 20:22 ` Daniel Shahaf
0 siblings, 1 reply; 7+ messages in thread
From: dana @ 2019-03-07 23:27 UTC (permalink / raw)
To: Adrian Vollmer; +Cc: zsh-workers
On 7 Mar 2019, at 13:23, Adrian Vollmer <zsh@vollmer.syss.de> wrote:
>to reproduce this bug, set showSignature = true in the log section of
>your global git config file, then type git reset <TAB> in a git repo
>that has a recent signed commit in its history.
I guess this is the simple fix for this particular case. `git log` is called
in a few other places, too, but i'm not sure if they're problematic. Probably
are and i just don't know how to trigger it.
Maybe it would make sense to do something more robust instead, though? For
example, we could have a __git_call wrapper around _call_program that always
calls git with a safe set of -c options, &c. It'd be a lot of lines changed,
but any further issues like this could be fixed in one place. idk.
dana
diff --git a/Completion/Unix/Command/_git b/Completion/Unix/Command/_git
index e5e4ee768..796a98fd5 100644
--- a/Completion/Unix/Command/_git
+++ b/Completion/Unix/Command/_git
@@ -6517,7 +6517,7 @@ __git_recent_commits () {
# Careful: most %d will expand to the empty string. Quote properly!
# NOTE: we could use %D directly, but it's not available in git 1.9.1 at least.
- commits=("${(f)"$(_call_program commits git --no-pager log ${(q)commit_opts} -20 --format='%h%n%d%n%s\ \(%cr\)%n%p')"}")
+ commits=("${(f)"$(_call_program commits git -c log.showSignature=false --no-pager log ${(q)commit_opts} -20 --format='%h%n%d%n%s\ \(%cr\)%n%p')"}")
__git_command_successful $pipestatus || return 1
for i j k parents in "$commits[@]" ; do
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: Bug in git tab completion: If git.showSignature = true is set globally, tab completion of commits is garbled
2019-03-07 23:27 ` dana
@ 2019-03-08 20:22 ` Daniel Shahaf
2019-03-09 16:25 ` dana
0 siblings, 1 reply; 7+ messages in thread
From: Daniel Shahaf @ 2019-03-08 20:22 UTC (permalink / raw)
To: dana; +Cc: zsh-workers, Adrian Vollmer
dana wrote on Thu, 07 Mar 2019 23:28 +00:00:
> On 7 Mar 2019, at 13:23, Adrian Vollmer <zsh@vollmer.syss.de> wrote:
> >to reproduce this bug, set showSignature = true in the log section of
> >your global git config file, then type git reset <TAB> in a git repo
> >that has a recent signed commit in its history.
>
> I guess this is the simple fix for this particular case. `git log` is called
> in a few other places, too, but i'm not sure if they're problematic. Probably
> are and i just don't know how to trigger it.
>
> Maybe it would make sense to do something more robust instead, though? For
> example, we could have a __git_call wrapper around _call_program that always
> calls git with a safe set of -c options, &c. It'd be a lot of lines changed,
> but any further issues like this could be fixed in one place. idk.
>
Should we use git-rev-list(1) instead of git-log(1)? The former is a
plumbing command, so should be the more appropriate interface for this
use-case.
My git(1) does not have the log.showSignature option so I couldn't test
this. (The knob is missing from _git-config() too.)
Cheers,
Daniel
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: Bug in git tab completion: If git.showSignature = true is set globally, tab completion of commits is garbled
2019-03-08 20:22 ` Daniel Shahaf
@ 2019-03-09 16:25 ` dana
2019-03-09 16:43 ` Daniel Shahaf
0 siblings, 1 reply; 7+ messages in thread
From: dana @ 2019-03-09 16:25 UTC (permalink / raw)
To: Daniel Shahaf; +Cc: zsh-workers, Adrian Vollmer
On 8 Mar 2019, at 14:22, Daniel Shahaf <d.s@daniel.shahaf.name> wrote:
>Should we use git-rev-list(1) instead of git-log(1)? The former is a
>plumbing command, so should be the more appropriate interface for this
>use-case.
Not sure. For a plumbing command it leaves a bit to be desired; it has no -z
and it doesn't really respect the format you tell it to use. In fact the
'commit 1234567890...' header it prints is actually hard-coded. It *does* seem
to ignore --show-signature/log.showSignature though, so i suppose it would
solve that problem
dana
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: Bug in git tab completion: If git.showSignature = true is set globally, tab completion of commits is garbled
2019-03-09 16:25 ` dana
@ 2019-03-09 16:43 ` Daniel Shahaf
2019-03-09 23:37 ` dana
0 siblings, 1 reply; 7+ messages in thread
From: Daniel Shahaf @ 2019-03-09 16:43 UTC (permalink / raw)
To: dana; +Cc: zsh-workers, Adrian Vollmer
dana wrote on Sat, 09 Mar 2019 16:26 +00:00:
> On 8 Mar 2019, at 14:22, Daniel Shahaf <d.s@daniel.shahaf.name> wrote:
> >Should we use git-rev-list(1) instead of git-log(1)? The former is a
> >plumbing command, so should be the more appropriate interface for this
> >use-case.
>
> Not sure. For a plumbing command it leaves a bit to be desired; it has no -z
It does have %x00, though.
> and it doesn't really respect the format you tell it to use. In fact the
> 'commit 1234567890...' header it prints is actually hard-coded.
Huh. Odd, but I think we can live with that: we can just have _git
discard the hardcoded header line that git emits. All we really care
about is that future git versions will continue to emit that line. I
assume they will, for compatibility reasons.
Cheers,
Daniel
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: Bug in git tab completion: If git.showSignature = true is set globally, tab completion of commits is garbled
2019-03-09 16:43 ` Daniel Shahaf
@ 2019-03-09 23:37 ` dana
2019-03-10 16:20 ` Daniel Shahaf
0 siblings, 1 reply; 7+ messages in thread
From: dana @ 2019-03-09 23:37 UTC (permalink / raw)
To: Daniel Shahaf; +Cc: zsh-workers, Adrian Vollmer
On 9 Mar 2019, at 10:43, Daniel Shahaf <d.s@daniel.shahaf.name> wrote:
>Huh. Odd, but I think we can live with that: we can just have _git
>discard the hardcoded header line that git emits. All we really care
>about is that future git versions will continue to emit that line. I
>assume they will, for compatibility reasons.
In that case, i think it would be something like this? I didn't test very
extensively (not even sure which paths exactly lead to these commands), but it
does seem to work for the scenario at hand
(--oneline is hard-coded to not print the hard-coded header)
dana
diff --git a/Completion/Unix/Command/_git b/Completion/Unix/Command/_git
index e5e4ee768..4eb07e921 100644
--- a/Completion/Unix/Command/_git
+++ b/Completion/Unix/Command/_git
@@ -5652,7 +5652,7 @@ __git_describe_branch () {
local __c
local -a __commits
for __c in ${(P)__commits_in}; do
- __commits+=("${__c}:${$(_call_program describe git log -1 --oneline $__c)//:/\\:}")
+ __commits+=("${__c}:${$(_call_program describe git rev-list -1 --oneline $__c)//:/\\:}")
done
_describe -t $__tag $__desc __commits "$@"
else
@@ -6493,8 +6493,9 @@ __git_commit_objects () {
# Note: the after-the-colon part must be unique across the entire array;
# see workers/34768
- commits=(${(f)"$(_call_program commits git --no-pager log -1000 --all --reflog --format='%h:\[%h\]\ %s\ \(%cr\)')"})
+ commits=(${(f)"$(_call_program commits git --no-pager rev-list -1000 --all --reflog --format='%h:\[%h\]\ %s\ \(%cr\)' HEAD)"})
__git_command_successful $pipestatus || return 1
+ commits=(${commits:#commit [[:xdigit:]](#c40,)})
_describe -Vx -t commits 'commit object name' commits
}
@@ -6503,7 +6504,7 @@ __git_commit_objects () {
__git_recent_commits () {
local gitdir expl start
declare -a descr tags heads commits argument_array_names commit_opts
- local i j k ret
+ local h i j k ret
integer distance_from_head
local label
local parents
@@ -6517,10 +6518,11 @@ __git_recent_commits () {
# Careful: most %d will expand to the empty string. Quote properly!
# NOTE: we could use %D directly, but it's not available in git 1.9.1 at least.
- commits=("${(f)"$(_call_program commits git --no-pager log ${(q)commit_opts} -20 --format='%h%n%d%n%s\ \(%cr\)%n%p')"}")
+ commits=("${(f)"$(_call_program commits git --no-pager rev-list ${(q)commit_opts} -20 --format='%h%n%d%n%s\ \(%cr\)%n%p' HEAD)"}")
__git_command_successful $pipestatus || return 1
- for i j k parents in "$commits[@]" ; do
+ # h => hard-coded 'commit abcdef1234567890...' -- just discarded
+ for h i j k parents in "$commits[@]" ; do
# Note: the after-the-colon part must be unique across the entire array;
# see workers/34768
if (( $#commit_opts )); then
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: Bug in git tab completion: If git.showSignature = true is set globally, tab completion of commits is garbled
2019-03-09 23:37 ` dana
@ 2019-03-10 16:20 ` Daniel Shahaf
0 siblings, 0 replies; 7+ messages in thread
From: Daniel Shahaf @ 2019-03-10 16:20 UTC (permalink / raw)
To: dana; +Cc: zsh-workers, Adrian Vollmer
dana wrote on Sat, Mar 09, 2019 at 17:37:47 -0600:
> On 9 Mar 2019, at 10:43, Daniel Shahaf <d.s@daniel.shahaf.name> wrote:
> >Huh. Odd, but I think we can live with that: we can just have _git
> >discard the hardcoded header line that git emits. All we really care
> >about is that future git versions will continue to emit that line. I
> >assume they will, for compatibility reasons.
>
> In that case, i think it would be something like this? I didn't test very
> extensively (not even sure which paths exactly lead to these commands), but it
> does seem to work for the scenario at hand
Looks good. Thanks. More below regarding the codepaths to these.
> +++ b/Completion/Unix/Command/_git
> @@ -5652,7 +5652,7 @@ __git_describe_branch () {
Looking at the callers of this, it should be used by «git checkout <TAB>» (one
of the alternatives is "basenames" of remote branches), refspecs in «git push
$remote …», etc; but an easier way to test this would be to run
.
compdef __git_describe_commit f
f <TAB>
.
interactively.
> @@ -6493,8 +6493,9 @@ __git_commit_objects () {
This function completes hashes of commits, as output by `git log --pretty=%h`.
It's used by _git-send-email. (I'm surprised that it isn't used by
_git-format-patch; those two commands are very similar.)
> @@ -6517,10 +6518,11 @@ __git_recent_commits () {
This is used by «git commit --fixup=<TAB>».
Cheers,
Daniel
^ permalink raw reply [flat|nested] 7+ messages in thread
end of thread, other threads:[~2019-03-10 16:21 UTC | newest]
Thread overview: 7+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2019-03-07 19:23 Bug in git tab completion: If git.showSignature = true is set globally, tab completion of commits is garbled Adrian Vollmer
2019-03-07 23:27 ` dana
2019-03-08 20:22 ` Daniel Shahaf
2019-03-09 16:25 ` dana
2019-03-09 16:43 ` Daniel Shahaf
2019-03-09 23:37 ` dana
2019-03-10 16:20 ` Daniel Shahaf
Code repositories for project(s) associated with this public inbox
https://git.vuxu.org/mirror/zsh/
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).