The user can be presented with invalid completion results
when trying to complete a 'git checkout' command. This can happen
when using a branch name prefix that matches multiple remote branches.
For example if available branches are:
master
remotes/GitHub/maint
remotes/GitHub/master
remotes/origin/maint
remotes/origin/master
When performing completion on 'git checkout ma' the user will be
given the choices:
maint
master
However, 'git checkout maint' will fail in this case, although
completion previously said 'maint' was valid.
Furthermore, when performing completion on 'git checkout mai',
no choices will be suggested. So, the user is first told that the
branch name 'maint' is valid, but when trying to complete 'mai'
into 'maint', that completion is no longer valid.
The completion results should never propose 'maint' as a valid
branch name, since 'git checkout' will refuse it.
The reason for this bug is that the uniq program only
works with sorted input. The man page states
"uniq prints the unique lines in a sorted file".
When __git_refs uses the guess heuristic employed by checkout for
tracking branches it wants to consider remote branches but only if
the branch name is unique. To do that, it calls 'uniq -u'. However
the input given to 'uniq -u' is not sorted.
Therefore, in the above example, when dealing with 'git checkout ma',
"__git_refs '' 1" will find the following list:
master
maint
master
maint
master
which, when passed to 'uniq -u' will remain the same. Therefore
'maint' will be wrongly suggested as a valid option.
When dealing with 'git checkout mai', the list will be:
maint
maint
which happens to be sorted and will be emptied by 'uniq -u',
properly ignoring 'maint'.
A solution for preventing the completion script from suggesting
such invalid branch names is to first call 'sort' and then 'uniq -u'.
Signed-off-by: Marc Khouzam <marc.khouzam@xxxxxxxxx>
---
>> The solution is to first call 'sort' and then 'uniq -u'.
>
> The solution to what? This seems to be the right thing indeed, but you
> don't explain what is the actual problem that is being solved. What
> does the user experience? What would (s)he experience after the patch?
I have re-worked the commit message to be more clear about the user
impacts.
Thanks for the feedback.
Marc
contrib/completion/git-completion.bash | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/contrib/completion/git-completion.bash
b/contrib/completion/git-completion.bash
index bc0657a..85ae419 100644
--- a/contrib/completion/git-completion.bash
+++ b/contrib/completion/git-completion.bash
@@ -321,7 +321,7 @@ __git_refs ()
if [[ "$ref" == "$cur"* ]]; then
echo "$ref"
fi
- done | uniq -u
+ done | sort | uniq -u
fi
return
fi
--
1.8.0.1.g9fe2839
--
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