* [PATCH 0/3] Completion/Unix/Command/_git: misc fixes @ 2013-04-20 12:56 Ramkumar Ramachandra 2013-04-20 12:56 ` [PATCH 1/3] Completion/Unix/Command/_git: add a couple of browsers Ramkumar Ramachandra ` (3 more replies) 0 siblings, 4 replies; 22+ messages in thread From: Ramkumar Ramachandra @ 2013-04-20 12:56 UTC (permalink / raw) To: ZSH Workers; +Cc: Clint Adams, Frank Terbeck, Nikolai Weibull 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 ^ permalink raw reply [flat|nested] 22+ messages in thread
* [PATCH 1/3] Completion/Unix/Command/_git: add a couple of browsers 2013-04-20 12:56 [PATCH 0/3] Completion/Unix/Command/_git: misc fixes Ramkumar Ramachandra @ 2013-04-20 12:56 ` Ramkumar Ramachandra 2013-04-20 12:56 ` [PATCH 2/3] Completion/Unix/Command/_git: fix shortlog completer Ramkumar Ramachandra ` (2 subsequent siblings) 3 siblings, 0 replies; 22+ messages in thread From: Ramkumar Ramachandra @ 2013-04-20 12:56 UTC (permalink / raw) To: ZSH Workers; +Cc: Clint Adams, Frank Terbeck, Nikolai Weibull 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 ^ permalink raw reply [flat|nested] 22+ messages in thread
* [PATCH 2/3] Completion/Unix/Command/_git: fix shortlog completer 2013-04-20 12:56 [PATCH 0/3] Completion/Unix/Command/_git: misc fixes Ramkumar Ramachandra 2013-04-20 12:56 ` [PATCH 1/3] Completion/Unix/Command/_git: add a couple of browsers Ramkumar Ramachandra @ 2013-04-20 12:56 ` Ramkumar Ramachandra 2013-04-20 13:03 ` Nikolai Weibull 2013-04-25 12:42 ` Frank Terbeck 2013-04-20 12:56 ` [PATCH 3/3] Completion/Unix/Command/_git: branch.*.pushremote, remote.pushdefault Ramkumar Ramachandra 2013-04-21 10:16 ` [PATCH 0/3] Completion/Unix/Command/_git: misc fixes Frank Terbeck 3 siblings, 2 replies; 22+ messages in thread From: Ramkumar Ramachandra @ 2013-04-20 12:56 UTC (permalink / raw) To: ZSH Workers; +Cc: Clint Adams, Frank Terbeck, Nikolai Weibull 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 ^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: [PATCH 2/3] Completion/Unix/Command/_git: fix shortlog completer 2013-04-20 12:56 ` [PATCH 2/3] Completion/Unix/Command/_git: fix shortlog completer Ramkumar Ramachandra @ 2013-04-20 13:03 ` Nikolai Weibull 2013-04-20 15:05 ` Frank Terbeck 2013-04-25 12:42 ` Frank Terbeck 1 sibling, 1 reply; 22+ messages in thread From: Nikolai Weibull @ 2013-04-20 13:03 UTC (permalink / raw) To: Ramkumar Ramachandra Cc: ZSH Workers, Clint Adams, Frank Terbeck, 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. ^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: [PATCH 2/3] Completion/Unix/Command/_git: fix shortlog completer 2013-04-20 13:03 ` Nikolai Weibull @ 2013-04-20 15:05 ` Frank Terbeck 2013-04-20 17:13 ` Ramkumar Ramachandra 0 siblings, 1 reply; 22+ messages in thread From: Frank Terbeck @ 2013-04-20 15:05 UTC (permalink / raw) To: Nikolai Weibull Cc: Ramkumar Ramachandra, ZSH Workers, Clint Adams, 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 ^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: [PATCH 2/3] Completion/Unix/Command/_git: fix shortlog completer 2013-04-20 15:05 ` Frank Terbeck @ 2013-04-20 17:13 ` Ramkumar Ramachandra 2013-04-20 17:35 ` Bart Schaefer 0 siblings, 1 reply; 22+ messages in thread From: Ramkumar Ramachandra @ 2013-04-20 17:13 UTC (permalink / raw) To: Frank Terbeck; +Cc: Nikolai Weibull, ZSH Workers, Frank Terbeck [-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. ^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: [PATCH 2/3] Completion/Unix/Command/_git: fix shortlog completer 2013-04-20 17:13 ` Ramkumar Ramachandra @ 2013-04-20 17:35 ` Bart Schaefer 2013-04-20 17:50 ` Ramkumar Ramachandra 0 siblings, 1 reply; 22+ messages in thread From: Bart Schaefer @ 2013-04-20 17:35 UTC (permalink / raw) To: ZSH Workers 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. ^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: [PATCH 2/3] Completion/Unix/Command/_git: fix shortlog completer 2013-04-20 17:35 ` Bart Schaefer @ 2013-04-20 17:50 ` Ramkumar Ramachandra 0 siblings, 0 replies; 22+ messages in thread From: Ramkumar Ramachandra @ 2013-04-20 17:50 UTC (permalink / raw) To: Bart Schaefer; +Cc: ZSH Workers 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. ^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: [PATCH 2/3] Completion/Unix/Command/_git: fix shortlog completer 2013-04-20 12:56 ` [PATCH 2/3] Completion/Unix/Command/_git: fix shortlog completer Ramkumar Ramachandra 2013-04-20 13:03 ` Nikolai Weibull @ 2013-04-25 12:42 ` Frank Terbeck 2013-04-25 13:11 ` Nikolai Weibull 2013-04-25 17:48 ` Ramkumar Ramachandra 1 sibling, 2 replies; 22+ messages in thread From: Frank Terbeck @ 2013-04-25 12:42 UTC (permalink / raw) To: zsh-workers 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 ^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: [PATCH 2/3] Completion/Unix/Command/_git: fix shortlog completer 2013-04-25 12:42 ` Frank Terbeck @ 2013-04-25 13:11 ` Nikolai Weibull 2013-04-25 18:12 ` Ramkumar Ramachandra 2013-04-25 17:48 ` Ramkumar Ramachandra 1 sibling, 1 reply; 22+ messages in thread From: Nikolai Weibull @ 2013-04-25 13:11 UTC (permalink / raw) To: Frank Terbeck; +Cc: zsh-workers 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 ^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: [PATCH 2/3] Completion/Unix/Command/_git: fix shortlog completer 2013-04-25 13:11 ` Nikolai Weibull @ 2013-04-25 18:12 ` Ramkumar Ramachandra 0 siblings, 0 replies; 22+ messages in thread From: Ramkumar Ramachandra @ 2013-04-25 18:12 UTC (permalink / raw) To: Nikolai Weibull; +Cc: Frank Terbeck, zsh-workers 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? ^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: [PATCH 2/3] Completion/Unix/Command/_git: fix shortlog completer 2013-04-25 12:42 ` Frank Terbeck 2013-04-25 13:11 ` Nikolai Weibull @ 2013-04-25 17:48 ` Ramkumar Ramachandra 2013-04-25 19:06 ` Frank Terbeck 1 sibling, 1 reply; 22+ messages in thread From: Ramkumar Ramachandra @ 2013-04-25 17:48 UTC (permalink / raw) To: Frank Terbeck; +Cc: zsh-workers 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. ^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: [PATCH 2/3] Completion/Unix/Command/_git: fix shortlog completer 2013-04-25 17:48 ` Ramkumar Ramachandra @ 2013-04-25 19:06 ` Frank Terbeck 2013-04-27 8:56 ` Nikolai Weibull 2013-04-27 10:22 ` Ramkumar Ramachandra 0 siblings, 2 replies; 22+ messages in thread From: Frank Terbeck @ 2013-04-25 19:06 UTC (permalink / raw) To: Ramkumar Ramachandra; +Cc: zsh-workers, Nikolai Weibull 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 ^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: [PATCH 2/3] Completion/Unix/Command/_git: fix shortlog completer 2013-04-25 19:06 ` Frank Terbeck @ 2013-04-27 8:56 ` Nikolai Weibull 2013-04-27 9:01 ` Nikolai Weibull 2013-04-28 14:30 ` Nikolai Weibull 2013-04-27 10:22 ` Ramkumar Ramachandra 1 sibling, 2 replies; 22+ messages in thread From: Nikolai Weibull @ 2013-04-27 8:56 UTC (permalink / raw) To: Frank Terbeck; +Cc: Ramkumar Ramachandra, zsh-workers 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. ^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: [PATCH 2/3] Completion/Unix/Command/_git: fix shortlog completer 2013-04-27 8:56 ` Nikolai Weibull @ 2013-04-27 9:01 ` Nikolai Weibull 2013-04-28 14:30 ` Nikolai Weibull 1 sibling, 0 replies; 22+ messages in thread From: Nikolai Weibull @ 2013-04-27 9:01 UTC (permalink / raw) To: Frank Terbeck; +Cc: Ramkumar Ramachandra, zsh-workers 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 ^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: [PATCH 2/3] Completion/Unix/Command/_git: fix shortlog completer 2013-04-27 8:56 ` Nikolai Weibull 2013-04-27 9:01 ` Nikolai Weibull @ 2013-04-28 14:30 ` Nikolai Weibull 2013-05-11 16:55 ` Nikolai Weibull 1 sibling, 1 reply; 22+ messages in thread From: Nikolai Weibull @ 2013-04-28 14:30 UTC (permalink / raw) To: zsh-workers 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? ^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: [PATCH 2/3] Completion/Unix/Command/_git: fix shortlog completer 2013-04-28 14:30 ` Nikolai Weibull @ 2013-05-11 16:55 ` Nikolai Weibull 2013-05-12 17:48 ` Peter Stephenson 0 siblings, 1 reply; 22+ messages in thread From: Nikolai Weibull @ 2013-05-11 16:55 UTC (permalink / raw) To: zsh-workers 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? ^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: [PATCH 2/3] Completion/Unix/Command/_git: fix shortlog completer 2013-05-11 16:55 ` Nikolai Weibull @ 2013-05-12 17:48 ` Peter Stephenson 0 siblings, 0 replies; 22+ messages in thread From: Peter Stephenson @ 2013-05-12 17:48 UTC (permalink / raw) To: zsh-workers 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/ ^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: [PATCH 2/3] Completion/Unix/Command/_git: fix shortlog completer 2013-04-25 19:06 ` Frank Terbeck 2013-04-27 8:56 ` Nikolai Weibull @ 2013-04-27 10:22 ` Ramkumar Ramachandra 2013-04-27 11:27 ` Frank Terbeck 1 sibling, 1 reply; 22+ messages in thread From: Ramkumar Ramachandra @ 2013-04-27 10:22 UTC (permalink / raw) To: Frank Terbeck; +Cc: zsh-workers, Nikolai Weibull 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. ^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: [PATCH 2/3] Completion/Unix/Command/_git: fix shortlog completer 2013-04-27 10:22 ` Ramkumar Ramachandra @ 2013-04-27 11:27 ` Frank Terbeck 0 siblings, 0 replies; 22+ messages in thread From: Frank Terbeck @ 2013-04-27 11:27 UTC (permalink / raw) To: Ramkumar Ramachandra; +Cc: zsh-workers, Nikolai Weibull 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 ^ permalink raw reply [flat|nested] 22+ messages in thread
* [PATCH 3/3] Completion/Unix/Command/_git: branch.*.pushremote, remote.pushdefault 2013-04-20 12:56 [PATCH 0/3] Completion/Unix/Command/_git: misc fixes Ramkumar Ramachandra 2013-04-20 12:56 ` [PATCH 1/3] Completion/Unix/Command/_git: add a couple of browsers Ramkumar Ramachandra 2013-04-20 12:56 ` [PATCH 2/3] Completion/Unix/Command/_git: fix shortlog completer Ramkumar Ramachandra @ 2013-04-20 12:56 ` Ramkumar Ramachandra 2013-04-21 10:16 ` [PATCH 0/3] Completion/Unix/Command/_git: misc fixes Frank Terbeck 3 siblings, 0 replies; 22+ messages in thread From: Ramkumar Ramachandra @ 2013-04-20 12:56 UTC (permalink / raw) To: ZSH Workers; +Cc: Clint Adams, Frank Terbeck, Nikolai Weibull 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 ^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: [PATCH 0/3] Completion/Unix/Command/_git: misc fixes 2013-04-20 12:56 [PATCH 0/3] Completion/Unix/Command/_git: misc fixes Ramkumar Ramachandra ` (2 preceding siblings ...) 2013-04-20 12:56 ` [PATCH 3/3] Completion/Unix/Command/_git: branch.*.pushremote, remote.pushdefault Ramkumar Ramachandra @ 2013-04-21 10:16 ` Frank Terbeck 3 siblings, 0 replies; 22+ messages in thread From: Frank Terbeck @ 2013-04-21 10:16 UTC (permalink / raw) To: Ramkumar Ramachandra; +Cc: ZSH Workers, Frank Terbeck, Nikolai Weibull 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 ^ permalink raw reply [flat|nested] 22+ messages in thread
end of thread, other threads:[~2013-05-12 19:39 UTC | newest] Thread overview: 22+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2013-04-20 12:56 [PATCH 0/3] Completion/Unix/Command/_git: misc fixes Ramkumar Ramachandra 2013-04-20 12:56 ` [PATCH 1/3] Completion/Unix/Command/_git: add a couple of browsers Ramkumar Ramachandra 2013-04-20 12:56 ` [PATCH 2/3] Completion/Unix/Command/_git: fix shortlog completer Ramkumar Ramachandra 2013-04-20 13:03 ` Nikolai Weibull 2013-04-20 15:05 ` Frank Terbeck 2013-04-20 17:13 ` Ramkumar Ramachandra 2013-04-20 17:35 ` Bart Schaefer 2013-04-20 17:50 ` Ramkumar Ramachandra 2013-04-25 12:42 ` Frank Terbeck 2013-04-25 13:11 ` Nikolai Weibull 2013-04-25 18:12 ` Ramkumar Ramachandra 2013-04-25 17:48 ` Ramkumar Ramachandra 2013-04-25 19:06 ` Frank Terbeck 2013-04-27 8:56 ` Nikolai Weibull 2013-04-27 9:01 ` Nikolai Weibull 2013-04-28 14:30 ` Nikolai Weibull 2013-05-11 16:55 ` Nikolai Weibull 2013-05-12 17:48 ` Peter Stephenson 2013-04-27 10:22 ` Ramkumar Ramachandra 2013-04-27 11:27 ` Frank Terbeck 2013-04-20 12:56 ` [PATCH 3/3] Completion/Unix/Command/_git: branch.*.pushremote, remote.pushdefault Ramkumar Ramachandra 2013-04-21 10:16 ` [PATCH 0/3] Completion/Unix/Command/_git: misc fixes Frank Terbeck
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).