[PATCH 0/3] Completion/Unix/Command/_git: misc fixes

[PATCH 0/3] Completion/Unix/Command/_git: misc fixes

[Ramkumar Ramachandra]

Hi,

My initial itch was [2/3], as I'm a big user of shortlog.  I also
threw in [1/3] and [3/3] while reading through file.

Thanks.

Ramkumar Ramachandra (3):
  Completion/Unix/Command/_git: add a couple of browsers
  Completion/Unix/Command/_git: fix shortlog completer
  Completion/Unix/Command/_git: branch.*.pushremote, remote.pushdefault

 Completion/Unix/Command/_git | 31 ++++++++++++++++++++++++++++++-
 1 file changed, 30 insertions(+), 1 deletion(-)

-- 
1.8.2.1.506.gbce9ff0

[PATCH 1/3] Completion/Unix/Command/_git: add a couple of browsers

[Ramkumar Ramachandra]

Add google-chrome/chromium to the list of builtinbrowsers in
__git_browsers ().

Signed-off-by: Ramkumar Ramachandra <artagnon@gmail.com>
---
 Completion/Unix/Command/_git | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/Completion/Unix/Command/_git b/Completion/Unix/Command/_git
index 2b6a369..f1753aa 100644
--- a/Completion/Unix/Command/_git
+++ b/Completion/Unix/Command/_git
@@ -5896,6 +5896,8 @@ __git_browsers () {
   builtinbrowsers=(
     firefox
     iceweasel
+    google-chrome
+    chromium
     konquerer
     w3m
     links
-- 
1.8.2.1.506.gbce9ff0

[PATCH 2/3] Completion/Unix/Command/_git: fix shortlog completer

[Ramkumar Ramachandra]

Currently, __git-shortlog () says that 'git shortlog' can only accept
commits as arguments (probably because the official documentation says
this).  This is entirely untrue: shortlog can accept
commit-range-or-file, just like log can.  Fix the completer by copying
out segments from the __git-log () function.

Signed-off-by: Ramkumar Ramachandra <artagnon@gmail.com>
---
 Completion/Unix/Command/_git | 27 ++++++++++++++++++++++++++-
 1 file changed, 26 insertions(+), 1 deletion(-)

diff --git a/Completion/Unix/Command/_git b/Completion/Unix/Command/_git
index f1753aa..38b1d80 100644
--- a/Completion/Unix/Command/_git
+++ b/Completion/Unix/Command/_git
@@ -1298,7 +1298,8 @@ _git-shortlog () {
     '(-e --email)'{-e,--email}'[show email addres of each author]' \
     '-w-[linewrap the output]:: :->wrap' \
     $revision_options \
-    '*: :__git_commits' && ret=0
+    '(-)--[start file arguments]' \
+    '*:: :->commit-range-or-file' && ret=0
 
   case $state in
     (wrap)
@@ -1314,6 +1315,30 @@ _git-shortlog () {
         __git_guard_number 'line width'
       fi
       ;;
+    (commit-range-or-file)
+      case $CURRENT in
+        (1)
+          if [[ -n ${opt_args[(I)--]} ]]; then
+            __git_cached_files && ret=0
+          else
+            _alternative \
+              'commit-ranges::__git_commit_ranges' \
+              'cached-files::__git_cached_files' && ret=0
+          fi
+          ;;
+        (*)
+          # TODO: Write a wrapper function that checks whether we have a
+          # committish range or comittish and calls __git_tree_files
+          # appropriately.
+          if __git_is_committish_range $line[1]; then
+            __git_tree_files ${PREFIX:-.} $(__git_committish_range_last $line[1]) && ret=0
+          elif __git_is_committish $line[1]; then
+            __git_tree_files ${PREFIX:-.} $line[1] && ret=0
+          else
+            __git_cached_files && ret=0
+          fi
+          ;;
+      esac
   esac
 
   return ret
-- 
1.8.2.1.506.gbce9ff0

Re: [PATCH 2/3] Completion/Unix/Command/_git: fix shortlog completer

[Nikolai Weibull]

On Sat, Apr 20, 2013 at 2:56 PM, Ramkumar Ramachandra
<artagnon@gmail.com> wrote:
> Currently, __git-shortlog () says that 'git shortlog' can only accept
> commits as arguments (probably because the official documentation says
> this).

Most commands have actually been checked against code, but this might
be the case, yes.

> +    (commit-range-or-file)

Perhaps it’s time to add a helper function for this kind of context.

Re: [PATCH 2/3] Completion/Unix/Command/_git: fix shortlog completer

[Frank Terbeck]

Nikolai Weibull wrote:
> On Sat, Apr 20, 2013 at 2:56 PM, Ramkumar Ramachandra
> <artagnon@gmail.com> wrote:
[...]
>> +    (commit-range-or-file)
>
> Perhaps it’s time to add a helper function for this kind of context.

So, do we take this patch as well or do we want to spend time on
fleshing out the helper function? Both would work for me, to be
honest. :)

The other two patches looked good, I think.

Regards, Frank

Re: [PATCH 2/3] Completion/Unix/Command/_git: fix shortlog completer

[Ramkumar Ramachandra]

[-CC: Clint Adams; his email address seems to be bouncing email]

Frank Terbeck wrote:
> So, do we take this patch as well or do we want to spend time on
> fleshing out the helper function? Both would work for me, to be
> honest. :)

You can apply this as-is if you like: I'll submit a patch factoring
out this code into a fresh function soon.  In the meantime, can
someone tell me how to test _git quickly?  I don't want to have to
re-compile, install, and start a new shell to test a small change.

Besides, there are plenty of other related problems.  Off the top of my head:

1. There's only some small logic for invoking __git_committish_range.
What happens to other kinds of revision specs?  Think completions for
stuff like :/quuxery, pu@{1}^2~300, ..next, bar@{2 days ago},
v1.7-679-g3bee7fb etc.  It might be too hard to support everything,
but we can certainly improve over just a <since>..<until> range.

2. log, shortlog, and blame should use rev-spec-or-file (a generalized
version of commit-range-or-file).

3. reset, checkout, and grep should use treeish-or-file.

Thanks.

Re: [PATCH 2/3] Completion/Unix/Command/_git: fix shortlog completer

[Bart Schaefer]

On Apr 20, 10:43pm, Ramkumar Ramachandra wrote:
}
} In the meantime, can someone tell me how to test _git quickly? I don't
} want to have to re-compile, install, and start a new shell to test a
} small change.

Assuming your current working directory is the root of your git pull,

    fpath=($PWD/{Completion{,/**/_*(N:h)},Functions/*(/N)} $fpath)
    unfunction -m _git\*
    autoload -Uz $^fpath/_git*(N:t)

will probably do it.  There's a similar trick for module_path if you
need to test compiled modules, but it also requires creating module
aliases to satisfy inter-module naming dependencies.

Re: [PATCH 2/3] Completion/Unix/Command/_git: fix shortlog completer

[Ramkumar Ramachandra]

Bart Schaefer wrote:
> Assuming your current working directory is the root of your git pull,
>
>     fpath=($PWD/{Completion{,/**/_*(N:h)},Functions/*(/N)} $fpath)
>     unfunction -m _git\*
>     autoload -Uz $^fpath/_git*(N:t)
>
> will probably do it.

Works like a charm!  Thank you for this.

Maybe we should write some helpers for developers and put it in
contrib/ or something?  I can think of including this, a setting for
sh-indentation/sh-basic-offset + a hook for turning on
shell-script-mode for relevant files automatically for Emacs, and
something for Vim.

Re: [PATCH 2/3] Completion/Unix/Command/_git: fix shortlog completer

[Frank Terbeck]

Ramkumar Ramachandra wrote:
[...]
> ---
>  Completion/Unix/Command/_git | 27 ++++++++++++++++++++++++++-
>  1 file changed, 26 insertions(+), 1 deletion(-)
[...]

I stumbled across a message on the git development mailing list, in
which Ramkumar basically falls for Felipe's ramblings. And since I'm not
interested in shouting matches with that guy I'll just leave him be. In
related news, I just pushed this commit to the central repository as
well, because Ramkumar - on the git mailing list - stated that he'll
drop working on this particular completion immediately.

Indifferent regards, Frank

Re: [PATCH 2/3] Completion/Unix/Command/_git: fix shortlog completer

[Nikolai Weibull]

On Thu, Apr 25, 2013 at 2:42 PM, Frank Terbeck <ft@bewatermyfriend.org> wrote:
> Ramkumar Ramachandra wrote:

>>  Completion/Unix/Command/_git | 27 ++++++++++++++++++++++++++-
>>  1 file changed, 26 insertions(+), 1 deletion(-)

> I stumbled across a message on the git development mailing list, in
> which Ramkumar basically falls for Felipe's ramblings. And since I'm not
> interested in shouting matches with that guy I'll just leave him be. In
> related news, I just pushed this commit to the central repository as
> well, because Ramkumar - on the git mailing list - stated that he'll
> drop working on this particular completion immediately.

That’s too bad.  I had no idea Felipe’s FUD had spread beyond this
list and was actually detracting from our work further.

> Felipe wrote:
> The reason why I prefer git.git's bash completion is that it has taken
> years to develop, and using good development practices, borrowed from
> the mainline git process.

Ah, that’s the difference, then.  I/we just threw something together
over the weekend.

> Indifferent regards, Frank

Sad regards, Nikolai

Re: [PATCH 2/3] Completion/Unix/Command/_git: fix shortlog completer

[Ramkumar Ramachandra]

Nikolai Weibull wrote:
> Sad regards, Nikolai

Please don't be sad: there's nothing to be sad about.  Both
implementations are readily available to inspect, and we're all still
here.  It's not like someone died ;)

Let's list out the strengths and weaknesses of both the
implementations, and work on what we think can be improved easily.
It's a relatively straightforward task, no?

Re: [PATCH 2/3] Completion/Unix/Command/_git: fix shortlog completer

[Ramkumar Ramachandra]

Frank Terbeck wrote:
> I stumbled across a message on the git development mailing list, in
> which Ramkumar basically falls for Felipe's ramblings. And since I'm not
> interested in shouting matches with that guy I'll just leave him be. In
> related news, I just pushed this commit to the central repository as
> well, because Ramkumar - on the git mailing list - stated that he'll
> drop working on this particular completion immediately.

Hey, you can talk to me about it.  I don't know the entire history of
things, but I've seen a few emails in which Felipe causes some
unpleasantness on the list (so yes, I'm roughly aware of his strengths
and weaknesses).  I'm just an unbiased observer, and want to work
towards the common good.

Now, I'm a shell-scripting beginner and do not have the expertise to
fully evaluate zsh's completer versus git.git's completer.  From my
untrained eyes, zsh's completer looks more complete and comprehensive
but git.git's completer looks terse and less intimidating.  There is
definitely a noticeable difference in speed: git.git's completer is
much faster, and there's no doubt about that.

I want to work on the completer without fundamentally difficult
problems (because I can't fix those fundamentally difficult problems).
 Speed seems to be a big pain point in zsh's completer, and that seems
to be a very difficult problem to solve (I saw a few list emails about
it).  However, it looks like we can gradually make git.git's completer
more comprehensive.

That's all I really have.  Can you help me out, and tell me more?

I would really like for us all to work on one completer.

Re: [PATCH 2/3] Completion/Unix/Command/_git: fix shortlog completer

[Frank Terbeck]

Ramkumar Ramachandra wrote:
[...]
> Now, I'm a shell-scripting beginner and do not have the expertise to
> fully evaluate zsh's completer versus git.git's completer.  From my
> untrained eyes, zsh's completer looks more complete and comprehensive
> but git.git's completer looks terse and less intimidating.  There is
> definitely a noticeable difference in speed: git.git's completer is
> much faster, and there's no doubt about that.

It definitely is.  It does a bit less though.

It's also more up to date. And the reason for that is simple. Git is
still moving fairly fast, and the _git completion is basically written
and maintained by one guy. One. A few people tried to chip in every once
in a while (myself included), but since nobody of those people really
follows git's development too closely that's a battle you cannot win.

The thing with previous encounters (I'm recollecting from memory here,
and I hope I'm not too inaccurate) is that Felipe pretty much demanded,
not asked - demanded, that all features that slowed the completion down
should be removed, not be made optional - removed, even though the
original author (Nikolai) put a lot of time into realising those
features. He was also completely against putting time into finding the
root cause of the problems, so that maybe the additional features could
be kept and sped up - even though people told him, they liked those
features and they didn't see the impact (because they only get really
annoyingly relevant on large repositories like the linux kernel, which
not everybody works on - there is also not a lot of negative feedback on
these mailing lists or the freenode IRC channel about the _git
completion). Long story short, Felipe's rather hostile tone got him a
pretty short-spoken final reply from Nikolai, which he now shows off to
anyone who does or doesn't ask.


This whole _git business is rather off-putting and I'd like to avoid
putting any more time and energy into any "politics" that are involved
on either side. This is no fun. I don't want to get steamed up about
things like this.


> I want to work on the completer without fundamentally difficult
> problems (because I can't fix those fundamentally difficult problems).

Maybe Nikolai would be willing to try and tackle the more fundamental
problems.

> Speed seems to be a big pain point in zsh's completer, and that seems
> to be a very difficult problem to solve (I saw a few list emails about
> it).  However, it looks like we can gradually make git.git's completer
> more comprehensive.

This thing with speed is this: Yes, _git is slower than the bash
completion. But - at least when I last looked - _git will provide much
more useful suggestions depending on the context of the cursor position.
And I - personally - am happy to wait for, say, a second if that means I
can save several seconds selecting the right choice. However, some
completions are too slow on really large repositories. That would be a
useful area to improve - maybe make the slow smartness optional? I don't
know.

> That's all I really have.  Can you help me out, and tell me more?

The one thing, that _git lacks the most is able bodies. People, who are
willing to update the different sub-command handlers to the current git
development. Command --options, git-config options, new sub-commands.
You name it. Nikolai can't do it all on his own, unless _git is his only
project in life, which it is not.

> I would really like for us all to work on one completer.

Well, the bash and zsh completion mechanisms are pretty different. There
are some features that zsh provides, that you just can't map to bash.
That makes one source to rule them all rather hard. And besides, I don't
think Felipe would let any feature suggestion in that adds smartness to
bash's completer, that would impact any of his use-cases.

That being said, if git would provide a way of saying "The git-am
command supports the following flags [...] and the --directory option
expects the value type of value: ...", then bash and zsh could both
_generate_ completers based on that. Might be neat, but sounds like a
bit of work. ;)


Okay then. This is far more than I thought I'd ever write on the subject
again, but since you asked nicely, you deserved a reasonable answer.

Thanks for your patches and good luck with whichever completion you
decide to work on!

Regards, Frank

-- 
In protocol design, perfection has been reached not when there is
nothing left to add, but when there is nothing left to take away.
                                                  -- RFC 1925

Re: [PATCH 2/3] Completion/Unix/Command/_git: fix shortlog completer

[Nikolai Weibull]

On Thu, Apr 25, 2013 at 9:06 PM, Frank Terbeck <ft@bewatermyfriend.org> wrote:
> Ramkumar Ramachandra wrote:
> [...]
>> Now, I'm a shell-scripting beginner and do not have the expertise to
>> fully evaluate zsh's completer versus git.git's completer.  From my
>> untrained eyes, zsh's completer looks more complete and comprehensive
>> but git.git's completer looks terse and less intimidating.  There is
>> definitely a noticeable difference in speed: git.git's completer is
>> much faster, and there's no doubt about that.

> It's also more up to date. And the reason for that is simple. Git is
> still moving fairly fast, and the _git completion is basically written
> and maintained by one guy. One. A few people tried to chip in every once
> in a while (myself included), but since nobody of those people really
> follows git's development too closely that's a battle you cannot win.

Yes, this is definitely a problem, and something I can’t really assist
with at the moment.

> The thing with previous encounters (I'm recollecting from memory here,
> and I hope I'm not too inaccurate) is that Felipe pretty much demanded,
> not asked - demanded, that all features that slowed the completion down
> should be removed, not be made optional - removed, even though the
> original author (Nikolai) put a lot of time into realising those
> features.

Felipe seems to apply his bullying tactics to any project that doesn’t
do as he wishes, see, for example,
http://redmine.yorba.org/issues/6813

>> I want to work on the completer without fundamentally difficult
>> problems (because I can't fix those fundamentally difficult problems).
>
> Maybe Nikolai would be willing to try and tackle the more fundamental
> problems.

I sadly don’t have the time.

>> Speed seems to be a big pain point in zsh's completer, and that seems
>> to be a very difficult problem to solve (I saw a few list emails about
>> it).  However, it looks like we can gradually make git.git's completer
>> more comprehensive.

> This thing with speed is this: Yes, _git is slower than the bash
> completion. But - at least when I last looked - _git will provide much
> more useful suggestions depending on the context of the cursor position.
> And I - personally - am happy to wait for, say, a second if that means I
> can save several seconds selecting the right choice. However, some
> completions are too slow on really large repositories. That would be a
> useful area to improve - maybe make the slow smartness optional? I don't
> know.

Definitely, and it should already be possible.  You can override many
of the more complex helpers by overriding the commands that _git calls
to generate results.

I think the first thing we need to do is identify the pain points.

For example

  % git add ^I

takes close to a second to complete in a clean git.git.  I don’t quite
see why that is, but git ls-files takes almost 0.1 second to run and
seems to be the main problem.  Hard to get around using git ls-files,
though.

I see (via _complete_debug) that _git-add gets called twice because I have

zstyle ':completion:*' matcher-list 'm:{[:lower:]}={[:upper:]}'
'r:|[:.,_-]=** r:|=**'

in my .zshrc.

I guess that gitcdup and gitprefix can be cached in __git_files, which
would shave off about 0.1 seconds per call to _git-add.

Anyway, I mostly use Magit now, so I might not be the right maintainer anymore.

Re: [PATCH 2/3] Completion/Unix/Command/_git: fix shortlog completer

[Nikolai Weibull]

On Sat, Apr 27, 2013 at 10:56 AM, Nikolai Weibull <now@disu.se> wrote:

> Anyway, I mostly use Magit now, so I might not be the right maintainer anymore.

This being the case, here’s my TODO items that haven’t been DONE yet:

** Git completion
*** Add return 1 after any _message or _nothing?
*** Add support for url.*.insteadof=* for __git_any_repositories
*** git rm --cached should also complete files in the repository
*** git diff-index doesn’t work for the initial commit for
__git_changed-in-index_files
*** Check that all _alternative options are 'users:: _users', not
'users: :_users' or 'users::_users'
*** Change _arguments * && ret=0 to _arguments * && return 0
*** Change _call_function ret * && ret=0 to _call_function ret * && return ret
*** Use loops when $state may contain multiple items
*** Should we add && ret=0 to _guard and __git_guard_*?
*** Remove _git_command_successful
*** Check all uses of compadd
*** Check all uses of _call_program
*** Add = to all local
*** All commands (more or less) take --help|-h
*** Unify --help description
*** Add _git_arguments for describing argument specifications using
Git’s argument parser
    This will allow us to unify the --help command, any uses of --verbose and
    similar and so on.
*** Decide on terminology for show/display/report
*** A lot of short options should be specified with a + so that they
can take their argument in the same word
*** Tree-ish should bee treeish
*** __git_tags can, for, for example, git verify-tag, be a hexadecimal
object name
    How do we fix that?
*** Use compadd -a array instead of compadd $array
*** Git config ->days should complete __git_datetimes
*** Use __all_labels in tag loop for mergetool
*** Instead of -prefix * use if compset *
    There’s no need to check this twice.
*** OPT_BOOLEAN can be both --blah and --no-blah
    Oh, my, that’s going to be a lot of work.
*** Replace __git_guard_branch-name with __git_branches
    We don’t have _guard_files for _files

Re: [PATCH 2/3] Completion/Unix/Command/_git: fix shortlog completer

[Nikolai Weibull]

On Sat, Apr 27, 2013 at 10:56 AM, Nikolai Weibull <now@disu.se> wrote:

> I think the first thing we need to do is identify the pain points.

I would really appreciate some input on this.  What commands are slow,
where, and with which repositories?

Re: [PATCH 2/3] Completion/Unix/Command/_git: fix shortlog completer

[Nikolai Weibull]

On Sun, Apr 28, 2013 at 4:30 PM, Nikolai Weibull <now@disu.se> wrote:
> On Sat, Apr 27, 2013 at 10:56 AM, Nikolai Weibull <now@disu.se> wrote:
>
>> I think the first thing we need to do is identify the pain points.
>
> I would really appreciate some input on this.  What commands are slow,
> where, and with which repositories?

OK, so we’ve gotten no responses on this.  Shall I take it that there
are no commands for which completion is slow?

Re: [PATCH 2/3] Completion/Unix/Command/_git: fix shortlog completer

[Peter Stephenson]

On Sat, 11 May 2013 18:55:58 +0200
Nikolai Weibull <now@disu.se> wrote:
> On Sun, Apr 28, 2013 at 4:30 PM, Nikolai Weibull <now@disu.se> wrote:
> > On Sat, Apr 27, 2013 at 10:56 AM, Nikolai Weibull <now@disu.se> wrote:
> >
> >> I think the first thing we need to do is identify the pain points.
> >
> > I would really appreciate some input on this.  What commands are slow,
> > where, and with which repositories?
> 
> OK, so we’ve gotten no responses on this.  Shall I take it that there
> are no commands for which completion is slow?

The problem seemed to be with certain archives.  It looks like the
people with those archives aren't to be found in these parts...  Nothing
with the zsh archive is unusably slow, certainly, and that's the only
one I use with any frequency.  Completion after "git show" takes a
couple of seconds on this machine (a few years old now), but I've got no
feeling for how that's likely to scale.  It's significantly slower than
"git add", for example, so maybe the place to look is for time taken in
git commands.  However, like you I'm largely in the dark about "real"
problems.

I have been wondering about setting up (zsh) tag ordering so I don't get offered
things I don't use much, such as git tags, but the capabilities for that are
already there.  It probably doesn't make sense to limit things by default.
If we wanted to make it easier for people to do this it ought to be something
generic, not git-specific --- e.g. it might be nice to be able to hit a key
in a given context so that instead of completing it showed you the possible
tags and prompted you to decide what order you'd like them offering in.
(Unless you can already and I missed it.)

Just some random thoughts on the subject so it doesn't go completely quiet...

-- 
Peter Stephenson <p.w.stephenson@ntlworld.com>
Web page now at http://homepage.ntlworld.com/p.w.stephenson/

Re: [PATCH 2/3] Completion/Unix/Command/_git: fix shortlog completer

[Ramkumar Ramachandra]

Frank Terbeck wrote:
> It definitely is.  It does a bit less though.
>
> It's also more up to date. And the reason for that is simple. Git is
> still moving fairly fast, and the _git completion is basically written
> and maintained by one guy. One. A few people tried to chip in every once
> in a while (myself included), but since nobody of those people really
> follows git's development too closely that's a battle you cannot win.

Yeah, I saw the shortlog/ blame for each of them.  git.git's completer
has a _lot_ of contributors.  Tons of eyes looking at the code.

I follow git's development quite closely -- I'm quite active on the
mailing list.  Like I said before: I'm not taking sides, so there's no
"battle": it's a simple task of picking one completer, and merging the
other's strengths into it.

> The thing with previous encounters (I'm recollecting from memory here,
> and I hope I'm not too inaccurate) is that Felipe pretty much demanded,
> not asked - demanded, that all features that slowed the completion down
> should be removed, not be made optional - removed, even though the
> original author (Nikolai) put a lot of time into realising those
> features. He was also completely against putting time into finding the
> root cause of the problems, so that maybe the additional features could
> be kept and sped up - even though people told him, they liked those
> features and they didn't see the impact (because they only get really
> annoyingly relevant on large repositories like the linux kernel, which
> not everybody works on - there is also not a lot of negative feedback on
> these mailing lists or the freenode IRC channel about the _git
> completion). Long story short, Felipe's rather hostile tone got him a
> pretty short-spoken final reply from Nikolai, which he now shows off to
> anyone who does or doesn't ask.

Got it.  However, why are we talking about him?  We're not interested
in changing Felipe's behavior (even if we did have some magical way to
do that).  Let us focus on which completer to work on by looking at
the two completers.

> This whole _git business is rather off-putting and I'd like to avoid
> putting any more time and energy into any "politics" that are involved
> on either side. This is no fun. I don't want to get steamed up about
> things like this.

Why are you getting steamed up?  What politics are you talking about?
Someone on the internet has a rather strong opinion on zsh's
completer, and he tells it to whoever asks him.  That's it.

> This thing with speed is this: Yes, _git is slower than the bash
> completion. But - at least when I last looked - _git will provide much
> more useful suggestions depending on the context of the cursor position.
> And I - personally - am happy to wait for, say, a second if that means I
> can save several seconds selecting the right choice. However, some
> completions are too slow on really large repositories. That would be a
> useful area to improve - maybe make the slow smartness optional? I don't
> know.

The question is: which way to start work from?

I personally prefer git.git's completer, because snappiness is very
important to me.  I'm even a little annoyed with Magit, because of the
speed issue.

> Well, the bash and zsh completion mechanisms are pretty different. There
> are some features that zsh provides, that you just can't map to bash.
> That makes one source to rule them all rather hard. And besides, I don't
> think Felipe would let any feature suggestion in that adds smartness to
> bash's completer, that would impact any of his use-cases.

Isn't it a matter of writing a larger zsh wrapper?  Yes,
git-completion.zsh is small.

Felipe is nobody.  He doesn't control the git project, the completer,
or anything else.  The git mailing list is filled with extremely
sensible rational people.

> Thanks for your patches and good luck with whichever completion you
> decide to work on!

Thanks for the explanation.

Re: [PATCH 2/3] Completion/Unix/Command/_git: fix shortlog completer

[Frank Terbeck]

Ramkumar Ramachandra wrote:
> Frank Terbeck wrote:
[...]
>> follows git's development too closely that's a battle you cannot win.
[...]
> mailing list.  Like I said before: I'm not taking sides, so there's no
> "battle": it's a simple task of picking one completer, and merging the
> other's strengths into it.

That's not how I meant "battle". I meant that one person cannot keep up
with the rate at which git moves. I didn't mean it in the bash vs zsh
completion sense. If the bash completion works well, that's great.

[...]
>> completion). Long story short, Felipe's rather hostile tone got him a
>> pretty short-spoken final reply from Nikolai, which he now shows off to
>> anyone who does or doesn't ask.
>
> Got it.  However, why are we talking about him?  We're not interested
> in changing Felipe's behavior (even if we did have some magical way to
> do that).  Let us focus on which completer to work on by looking at
> the two completers.

I merely provided some context, but you've obviously got a point there. ;)

>> This whole _git business is rather off-putting and I'd like to avoid
>> putting any more time and energy into any "politics" that are involved
>> on either side. This is no fun. I don't want to get steamed up about
>> things like this.
>
> Why are you getting steamed up?  What politics are you talking about?
> Someone on the internet has a rather strong opinion on zsh's
> completer, and he tells it to whoever asks him.  That's it.

Discussing with reasonably mannered people is no problem at all. People
on the other hand, who are abusive and insulting for no particular
reason other than the effect it has on the people on the other side of
the "discussion" can be infuriating - which is obviously what they are
aiming for, but what can you do. ;)

I'd really like to follow your suggestion and drop this matter now.

>> This thing with speed is this: Yes, _git is slower than the bash
>> completion. But - at least when I last looked - _git will provide much
>> more useful suggestions depending on the context of the cursor position.
>> And I - personally - am happy to wait for, say, a second if that means I
>> can save several seconds selecting the right choice. However, some
>> completions are too slow on really large repositories. That would be a
>> useful area to improve - maybe make the slow smartness optional? I don't
>> know.
>
> The question is: which way to start work from?
[...]

I don't know. It seems that the two completers have different
philosophies in the ways they work, so merging them seems like a
long-running and tedious job.

Like I said before, having a source that describes possible completions
would be a step in the right direction. Also, non-bourne-like shells
like tcsh and fish could benefit from that.


Regards, Frank

-- 
In protocol design, perfection has been reached not when there is
nothing left to add, but when there is nothing left to take away.
                                                  -- RFC 1925

[PATCH 3/3] Completion/Unix/Command/_git: branch.*.pushremote, remote.pushdefault

[Ramkumar Ramachandra]

The configuration variables branch.*.pushremote and remote.pushdefault
are relatively new, and are currently not completed by ZSH.  Fix this.

Signed-off-by: Ramkumar Ramachandra <artagnon@gmail.com>
---
 Completion/Unix/Command/_git | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/Completion/Unix/Command/_git b/Completion/Unix/Command/_git
index 38b1d80..6b8f6b6 100644
--- a/Completion/Unix/Command/_git
+++ b/Completion/Unix/Command/_git
@@ -1744,6 +1744,7 @@ _git-config () {
     'branch.*.remote:what remote git fetch and git push should fetch form/push to::__git_remotes'
     'branch.*.merge:default refspec to be marked for merging::__git_ref_specs'
     'branch.*.mergeoptions:default options for merging::->branch.mergeoptions'
+    'branch.*.pushremote:what remote git push should push to::__git_remotes'
     'branch.*.rebase:rebase on top of fetched branch::->bool:false'
     'browser.*.cmd:browser command to use:browser:_path_commands'
     'browser.*.path:path to use for the browser:absolute browser path:_files -g "*(*)"'
@@ -1958,6 +1959,7 @@ _git-config () {
     receive.denyCurrentBranch:'deny a ref update of currently checked out branch::->receive.denyCurrentBranch'
     receive.denyNonFastForwards:'deny a ref update that is not a fast-forward::->bool:false'
     receive.updateserverinfo:'run git update-server-info after receiving data::->bool:false'
+    'remote.pushdefault:URL of a remote repository to pushto::__git_any_repositories'
     'remote.*.url:URL of a remote repository::__git_any_repositories'
     'remote.*.pushurl:push URL of a remote repository::__git_any_repositories'
     'remote.*.proxy:URL of proxy to use for a remote repository::_urls'
-- 
1.8.2.1.506.gbce9ff0

Re: [PATCH 0/3] Completion/Unix/Command/_git: misc fixes

[Frank Terbeck]

Hello Ramkumar,

Ramkumar Ramachandra wrote:
> My initial itch was [2/3], as I'm a big user of shortlog.  I also
> threw in [1/3] and [3/3] while reading through file.
[...]


I've pushed 1/3 and 3/3, since they are obviously correct.

You said you wanted to look a bit into refactoring some of the helper
functionality of 2/3, so I left it out for now.

Thanks for helping out!

Regards, Frank