Mostly cosmetic suggestions, but it looks OK to me.
On Fri, Nov 23, 2012 at 12:17 PM, Marc Khouzam <marc.khou...@gmail.com> wrote:
> 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:
For example; <- separation
> When performing completion on 'git checkout ma' the user will be
> given the choices:
> However, 'git checkout maint' will fail in this case, although
> completion previously said 'maint' was valid.
Space (or continue paragraph).
> 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.
With this explanation the patch looks good to me.
> 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:
> 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:
> 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'.
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