v3, 4 partsFix branch.autosetup(merge|rebase) completion

Hi Junio et al,

In v3, I've implemented __gitcomp_nl_append (), like you suggested. After implementing it, I feel foolish about having gone around my head to do __gitcomp_2 ().

Thanks.

Ramkumar Ramachandra (4):
  completion: prioritize ./git-completion.bash
  completion: introduce __gitcomp_nl_append ()
  completion: fix branch.autosetup(merge|rebase)
  completion: fix remote.pushdefault

 contrib/completion/git-completion.bash | 15 +++++++++++++++
 contrib/completion/git-completion.zsh  | 10 +++++++++-
 2 files changed, 24 insertions(+), 1 deletion(-)

To ease development, prioritize ./git-completion.bash over other standard system paths.

Signed-off-by: Ramkumar Ramachandra <artagnon@gmail.com>
---
 contrib/completion/git-completion.zsh | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

There are situations where multiple classes of completions possible. For example

  branch.<TAB>

should try to complete

  branch.master.
  branch.autosetupmerge
  branch.autosetuprebase

The first candidate has the suffix ".", and the second/ third candidates have the suffix " ". To facilitate completions of this kind, create a variation of __gitcomp_nl () that appends to the existing list of completion candidates, COMPREPLY.

Signed-off-by: Ramkumar Ramachandra <artagnon@gmail.com>
---
 contrib/completion/git-completion.bash | 13 +++++++++++++
 contrib/completion/git-completion.zsh  |  8 ++++++++
 2 files changed, 21 insertions(+)

Ramkumar Ramachandra <artagnon@gmail.com> writes:

Hmph. Why so much duplication with __gitcompadd, though.

I would have expected that this "append" behaviour to be done at the lower level by introducing __gitcompappend that does not forcibly truncate by starting from a hard-coded i=0, i.e. a collection of small helper functions plus a single implementation of the logic to push elements into COMPREPLY[] in __gitcompappend, perhaps like these:

	__gitcompappend () {
		local i=${#COMPREPLY[@]}
		for x in $1; do
                        if [[ "$x" == "$3"* ]]; then
                                COMPREPLY[i++]="$2$x$4"
                        fi
		done
        }

	__gitcompadd () {
		COMPREPLY=()
		__gitcompappend "$@"
	}

	__gitcomp_nl_append () {
		local IFS=$'\n'
                __gitcompappend "$1" "${2-}" "${3-$cur}" "${4- }"
        }

	__gitcomp_nl () {
		COMPREPLY=()
                __gitcomp_nl_append "$@"		
        }
        
Is it because going this route and doing it at such a low level
would make zsh completion (which I have no clue about ;-)
unnecessarily complex?

Junio C Hamano wrote:

The zsh completion only cares to override __gitcomp_nl () and __gitcomp_nl_append (), without bothering to re-implement the lower-level functions; so it's no problem at all. I wrote mine out by thinking of a non-intrusive direct translation, while your version focuses on eliminating duplication. I don't have a strong preference either way, so I will resubmit with your version.

When attempting to complete

  $ git config branch.auto<TAB>

'autosetupmerge' and 'autosetuprebase' don't come up. This is because "$cur" is matched with "branch.*" and a list of branches are completed. Add 'autosetupmerge', 'autosetuprebase' to the list of branches using __gitcomp_nl_append ().

Signed-off-by: Ramkumar Ramachandra <artagnon@gmail.com>
---
 contrib/completion/git-completion.bash | 1 +
 1 file changed, 1 insertion(+)

When attempting to complete

  $ git config remote.push<TAB>

'pushdefault' doesn't come up. This is because "$cur" is matched with "remote.*" and a list of remotes are completed. Add 'pushdefault' to the list of remotes using __gitcomp_nl_append ().

Signed-off-by: Ramkumar Ramachandra <artagnon@gmail.com>
---
 contrib/completion/git-completion.bash | 1 +
 1 file changed, 1 insertion(+)

Ramkumar Ramachandra <artagnon@gmail.com> writes:

"Add ... to the list of remotes" (same for "list of branches" in 3/4) sounds somewhat funny, doesn't it? How about

	Add remote.pushdefault as a candidate for completion, too.

or something like that instead?