* git-completion 1.2 released @ 2020-11-19 16:05 Felipe Contreras 2020-11-21 16:03 ` Daniel Shahaf 0 siblings, 1 reply; 9+ messages in thread From: Felipe Contreras @ 2020-11-19 16:05 UTC (permalink / raw) To: zsh-users Hello, Git-completion is a friendly fork of the official Git completion and prompt scripts for Zsh and Bash. The main goal is to provide a more up-to-date completion for Zsh (I'm the developer), which is basically just a wrapper around the Bash completion. Compared to Git upstream, you get many benefits for Zsh, for example: no extra unnecessary spaces, correct auto suffix removal, colors without PROMPT_COMMAND, custom aliases, fixed --no-options, and many more. If you use the official Zsh completion the main benefit is that it's blazingly fast. Simply doing "git log <tab>" on the Linux kernel (with 3k+ refs) takes several seconds on the official Zsh completion (about 3 seconds on my machine), with git-complete it's *instantaneous*. There's other benefits too. Since the Bash completion is actively maintained by Git developers, everything works as they intend too. For example "git send-email <tab>" correctly completes branches, as opposed to files in the Zsh official completion. Also, complex aliases such as '!f () { }; f' are correctly identified and completed out-of-the-box. It's a sister project of the Oh My Zsh gitfast plugin [1], which I maintain too. Since the last version a testing framework was added, and now all the completion tests of the Git project pass with the Zsh wrapper too [2]. For installation instructions, and more information, check the wiki [3], but basically. * make install * fpath=(~/.local/share/git-completion/zsh $fpath) Enjoy. [1] https://github.com/ohmyzsh/ohmyzsh/tree/master/plugins/gitfast [2] https://travis-ci.org/github/felipec/git-completion [3] https://github.com/felipec/git-completion/wiki/Zsh -- Felipe Contreras ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: git-completion 1.2 released 2020-11-19 16:05 git-completion 1.2 released Felipe Contreras @ 2020-11-21 16:03 ` Daniel Shahaf 2020-11-21 20:14 ` Bart Schaefer 2020-11-22 0:53 ` Felipe Contreras 0 siblings, 2 replies; 9+ messages in thread From: Daniel Shahaf @ 2020-11-21 16:03 UTC (permalink / raw) To: Felipe Contreras, zsh-users Felipe Contreras wrote on Thu, 19 Nov 2020 16:05 +00:00: > Git-completion is a friendly fork of the official Git completion and > prompt scripts for Zsh and Bash. > > The main goal is to provide a more up-to-date completion for Zsh (I'm > the developer), which is basically just a wrapper around the Bash > completion. I was going to invite you to send patches to zsh's own _git, but then I noticed that in README.asciidoc you claim that you've sent patches to zsh's completion and "many" of them have been "ignored": > > Most Git developers use the Bash shell, for which the completion scripts work > > rather well, however, Zsh is typically neglected. I've sent many patches to fix > > the issues, many have been merged, but many have been ignored, thus the need for > > a canonical location of a good, working Zsh completion. I went back through the archives (and by this I mean the _complete_ archives, all the way back to 1995) and looked for git-related patches and threads from you (using «~(~f Contreras ~s 'git|patch')» in Mutt, if anyone wonders). Here's what I found: In April 2011 you sent 29208, which was accepted; 29041, which was accepted; and 29055, which began a long thread that doesn't contain any unified diffs. I didn't read the thread in full since, according to the subsequent thread starting in 29158, the 29055 thread ended up in a disagreement not unlike the one you and Roman had just this week. I also saw your 31343 and 31415, but they don't contain patches. Which is to say, I have not found a _single_ patch from you that has been "ignored", and for that matter, I haven't found a single patch from you that has "not been merged", either; and the last _git-related disagreement between you and the zsh developers is almost a decade ago. Which is to say, I have failed to convince myself that the statement in your README.asciidoc is accurate. The invitation stands. > Compared to Git upstream, you get many benefits for Zsh, for example: > no extra unnecessary spaces, correct auto suffix removal, colors > without PROMPT_COMMAND, custom aliases, fixed --no-options, and many > more. I suspect some of these have been fixed in zsh's _git since you last looked and others are configurable. (E.g., git-send-email(1), which you mention below, completes not only files but also recent commits, and has done so for a while.) I also suspect that zsh's _git has features that yours lacks. > If you use the official Zsh completion the main benefit is that it's > blazingly fast. Simply doing "git log <tab>" on the Linux kernel (with > 3k+ refs) takes several seconds on the official Zsh completion (about > 3 seconds on my machine), with git-complete it's *instantaneous*. > Are you comparing apples to apples or to oranges? I.e., does it take more time to produce the _same set_ of result, or to produce a different set? > There's other benefits too. Since the Bash completion is actively > maintained by Git developers, everything works as they intend too. > > For example "git send-email <tab>" correctly completes branches, as > opposed to files in the Zsh official completion. Also, complex aliases > such as '!f () { }; f' are correctly identified and completed > out-of-the-box. > > It's a sister project of the Oh My Zsh gitfast plugin [1], which I maintain too. > > Since the last version a testing framework was added, and now all the > completion tests of the Git project pass with the Zsh wrapper too [2]. > > For installation instructions, and more information, check the wiki > [3], but basically. > > * make install > * fpath=(~/.local/share/git-completion/zsh $fpath) > > Enjoy. > > [1] https://github.com/ohmyzsh/ohmyzsh/tree/master/plugins/gitfast > [2] https://travis-ci.org/github/felipec/git-completion > [3] https://github.com/felipec/git-completion/wiki/Zsh > > -- > Felipe Contreras > > ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: git-completion 1.2 released 2020-11-21 16:03 ` Daniel Shahaf @ 2020-11-21 20:14 ` Bart Schaefer 2020-11-22 0:59 ` Felipe Contreras 2020-11-22 0:53 ` Felipe Contreras 1 sibling, 1 reply; 9+ messages in thread From: Bart Schaefer @ 2020-11-21 20:14 UTC (permalink / raw) To: Daniel Shahaf; +Cc: Felipe Contreras, Zsh Users On Sat, Nov 21, 2020 at 8:05 AM Daniel Shahaf <d.s@daniel.shahaf.name> wrote: > > I didn't read the thread in full since, according to the > subsequent thread starting in 29158, the 29055 thread ended up in > a disagreement not unlike the one you and Roman had just this week. I'm reminding myself now of the first few paragraphs of: https://www.zsh.org/mla/workers/2011/msg00510.html > I suspect some of these have been fixed in zsh's _git since you last > looked Indeed, referring again to that same article, we've done a lot of work the past couple of years on optimizing array operations etc. (thanks, Sebastian). ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: git-completion 1.2 released 2020-11-21 20:14 ` Bart Schaefer @ 2020-11-22 0:59 ` Felipe Contreras 0 siblings, 0 replies; 9+ messages in thread From: Felipe Contreras @ 2020-11-22 0:59 UTC (permalink / raw) To: Bart Schaefer; +Cc: Daniel Shahaf, Zsh Users On Sat, Nov 21, 2020 at 2:14 PM Bart Schaefer <schaefer@brasslantern.com> wrote: > On Sat, Nov 21, 2020 at 8:05 AM Daniel Shahaf <d.s@daniel.shahaf.name> wrote: > > I suspect some of these have been fixed in zsh's _git since you last > > looked > > Indeed, referring again to that same article, we've done a lot of work > the past couple of years on optimizing array operations etc. (thanks, > Sebastian). But the completion is still slow. It takes several seconds to produce an output in the Linux kernel tree on my system. -- Felipe Contreras ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: git-completion 1.2 released 2020-11-21 16:03 ` Daniel Shahaf 2020-11-21 20:14 ` Bart Schaefer @ 2020-11-22 0:53 ` Felipe Contreras 2020-11-23 4:33 ` Daniel Shahaf 1 sibling, 1 reply; 9+ messages in thread From: Felipe Contreras @ 2020-11-22 0:53 UTC (permalink / raw) To: Daniel Shahaf; +Cc: zsh-users On Sat, Nov 21, 2020 at 10:05 AM Daniel Shahaf <d.s@daniel.shahaf.name> wrote: > > Felipe Contreras wrote on Thu, 19 Nov 2020 16:05 +00:00: > > Git-completion is a friendly fork of the official Git completion and > > prompt scripts for Zsh and Bash. > > > > The main goal is to provide a more up-to-date completion for Zsh (I'm > > the developer), which is basically just a wrapper around the Bash > > completion. > > I was going to invite you to send patches to zsh's own _git, but then I > noticed that in README.asciidoc you claim that you've sent patches to > zsh's completion and "many" of them have been "ignored": Git's zsh completion, not Zsh's Git completion. > > Compared to Git upstream, you get many benefits for Zsh, for example: > > no extra unnecessary spaces, correct auto suffix removal, colors > > without PROMPT_COMMAND, custom aliases, fixed --no-options, and many > > more. > > I suspect some of these have been fixed in zsh's _git since you last > looked and others are configurable. (E.g., git-send-email(1), which you > mention below, completes not only files but also recent commits, and has > done so for a while.) But the main use of "git send-email" is not to receive random files, it's to receive comittishes, and potentially some .patch files. If I do "git send-email master..<tab>" nothing completes with Zsh's official completion. It does with mine. > I also suspect that zsh's _git has features that yours lacks. Of course, but unlikely any that Git developers themselves consider essential, since they are fine with Git's Bash completion. > > If you use the official Zsh completion the main benefit is that it's > > blazingly fast. Simply doing "git log <tab>" on the Linux kernel (with > > 3k+ refs) takes several seconds on the official Zsh completion (about > > 3 seconds on my machine), with git-complete it's *instantaneous*. > > > > Are you comparing apples to apples or to oranges? I.e., does it take > more time to produce the _same set_ of result, or to produce a > different set? I don't personally care. Git's official completion returns a list of more than 3,000 items. I don't think Zsh's Git completion returning *more* helps anyone. If it takes more for the completion system to return a completion; it's defeating its purpose. I'd rather type it myself. Cheers. -- Felipe Contreras ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: git-completion 1.2 released 2020-11-22 0:53 ` Felipe Contreras @ 2020-11-23 4:33 ` Daniel Shahaf 2020-11-23 7:49 ` Felipe Contreras 0 siblings, 1 reply; 9+ messages in thread From: Daniel Shahaf @ 2020-11-23 4:33 UTC (permalink / raw) To: Felipe Contreras; +Cc: zsh-users Felipe Contreras wrote on Sat, Nov 21, 2020 at 18:53:56 -0600: > On Sat, Nov 21, 2020 at 10:05 AM Daniel Shahaf <d.s@daniel.shahaf.name> wrote: > > > > Felipe Contreras wrote on Thu, 19 Nov 2020 16:05 +00:00: > > > Git-completion is a friendly fork of the official Git completion and > > > prompt scripts for Zsh and Bash. > > > > > > The main goal is to provide a more up-to-date completion for Zsh (I'm > > > the developer), which is basically just a wrapper around the Bash > > > completion. > > > > I was going to invite you to send patches to zsh's own _git, but then I > > noticed that in README.asciidoc you claim that you've sent patches to > > zsh's completion and "many" of them have been "ignored": > > Git's zsh completion, not Zsh's Git completion. Thanks for clarifying this. > > > Compared to Git upstream, you get many benefits for Zsh, for example: > > > no extra unnecessary spaces, correct auto suffix removal, colors > > > without PROMPT_COMMAND, custom aliases, fixed --no-options, and many > > > more. > > > > I suspect some of these have been fixed in zsh's _git since you last > > looked and others are configurable. (E.g., git-send-email(1), which you > > mention below, completes not only files but also recent commits, and has > > done so for a while.) > > But the main use of "git send-email" is not to receive random files, > it's to receive comittishes, and potentially some .patch files. > So, just this? Will anyone want to complete files that _don't_ have a .patch extension? diff --git a/Completion/Unix/Command/_git b/Completion/Unix/Command/_git index 81a060e4d..8d1567e39 100644 --- a/Completion/Unix/Command/_git +++ b/Completion/Unix/Command/_git @@ -4443,7 +4443,7 @@ _git-send-email () { '--force[send emails even if safety checks would prevent it]' \ '(- *)--dump-aliases[dump configured aliases and exit]' \ '*: : _alternative -O expl - "files:file:_files" + "files:file:_files -g \"*.patch\"" "commits:recent commit object name:__git_commit_objects_prefer_recent"' } > If I do "git send-email master..<tab>" nothing completes with Zsh's > official completion. It does with mine. Thanks for the bug report. ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: git-completion 1.2 released 2020-11-23 4:33 ` Daniel Shahaf @ 2020-11-23 7:49 ` Felipe Contreras 2020-11-23 15:44 ` Daniel Shahaf 0 siblings, 1 reply; 9+ messages in thread From: Felipe Contreras @ 2020-11-23 7:49 UTC (permalink / raw) To: Daniel Shahaf; +Cc: Zsh Users On Sun, Nov 22, 2020 at 10:34 PM Daniel Shahaf <d.s@daniel.shahaf.name> wrote: > Felipe Contreras wrote on Sat, Nov 21, 2020 at 18:53:56 -0600: > > But the main use of "git send-email" is not to receive random files, > > it's to receive comittishes, and potentially some .patch files. > > So, just this? Will anyone want to complete files that _don't_ have > a .patch extension? Usually "git send-email" receives the patches generated by "git format-patch", so yeah, *.patch should be enough. But it probably wouldn't hurt to add *.diff files too, just in case. > > If I do "git send-email master..<tab>" nothing completes with Zsh's > > official completion. It does with mine. > > Thanks for the bug report. You're welcome. But that's just an example. Another example is that "git -C ~/dev/git show <tab>" doesn't work, and the _git function has a TODO about -c since 2011. And there's a lot of others. I did some hacks to run Zsh's official Git completion against Git's testing framework, and at least half of them fail. I could tell you how to do that if you are interested. So in my view it's clear the priorities of the two completions are very different. Cheers. -- Felipe Contreras ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: git-completion 1.2 released 2020-11-23 7:49 ` Felipe Contreras @ 2020-11-23 15:44 ` Daniel Shahaf 2020-11-23 18:31 ` Felipe Contreras 0 siblings, 1 reply; 9+ messages in thread From: Daniel Shahaf @ 2020-11-23 15:44 UTC (permalink / raw) To: Felipe Contreras; +Cc: Zsh Users Felipe Contreras wrote on Mon, Nov 23, 2020 at 01:49:16 -0600: > On Sun, Nov 22, 2020 at 10:34 PM Daniel Shahaf <d.s@daniel.shahaf.name> wrote: > > Felipe Contreras wrote on Sat, Nov 21, 2020 at 18:53:56 -0600: > > > > But the main use of "git send-email" is not to receive random files, > > > it's to receive comittishes, and potentially some .patch files. > > > > So, just this? Will anyone want to complete files that _don't_ have > > a .patch extension? > > Usually "git send-email" receives the patches generated by "git > format-patch", so yeah, *.patch should be enough. But it probably > wouldn't hurt to add *.diff files too, just in case. Let's do that for 5.9, then. Thanks. > > > If I do "git send-email master..<tab>" nothing completes with Zsh's > > > official completion. It does with mine. > > > > Thanks for the bug report. > > You're welcome. > > But that's just an example. Another example is that "git -C ~/dev/git > show <tab>" doesn't work, That looks straightforward to add, considering the --git-dir/--work-tree support already in place. > and the _git function has a TODO about -c since 2011. That TODO is so vague that it may well have been fixed at some point in the intervening decade. For instance, it so happens that I did a bunch of work on -c, but that work was in _git-config and I never saw that TODO comment until now. I suspect that TODO comment should simply be deleted for vagueness, especially given its age. > And there's a lot of others. > If so, they haven't been reported. We can't fix bugs unless they are reported to us. > I did some hacks to run Zsh's official Git completion against Git's > testing framework, and at least half of them fail. I could tell you > how to do that if you are interested. Thanks for the offer. We would be interested, if the results could be used without licensing concerns. zsh's _git is BSD-licensed. > So in my view it's clear the priorities of the two completions are > very different. It's nothing as deliberate as that. It's more likely just that nobody ever reported the bug whilst someone able and inclined to fix it happened to be listening. Also, in the specific case of «git -C», the Git maintainers probably use that option far more often than the average zsh user does (to run their HEAD builds against test repositories). Cheers, Daniel (Will read the other emails later; got to leave now.) ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: git-completion 1.2 released 2020-11-23 15:44 ` Daniel Shahaf @ 2020-11-23 18:31 ` Felipe Contreras 0 siblings, 0 replies; 9+ messages in thread From: Felipe Contreras @ 2020-11-23 18:31 UTC (permalink / raw) To: Daniel Shahaf; +Cc: Zsh Users On Mon, Nov 23, 2020 at 9:44 AM Daniel Shahaf <d.s@daniel.shahaf.name> wrote: > > Felipe Contreras wrote on Mon, Nov 23, 2020 at 01:49:16 -0600: > I suspect that TODO comment should simply be deleted for vagueness, > especially given its age. I suspect so too. It seems Nikolai Weibull added that comment for some reason in 2011 but he hasn't been active for a lot of time and nobody removed it. > > And there's a lot of others. > > If so, they haven't been reported. We can't fix bugs unless they are > reported to us. Well, I do fix bugs before they are reported, because I use git all the time, and I use git completion all the time, and I also developed a testing framework for the completion so users don't have to be bitten by bugs in order to find them. > > I did some hacks to run Zsh's official Git completion against Git's > > testing framework, and at least half of them fail. I could tell you > > how to do that if you are interested. > > Thanks for the offer. We would be interested, if the results could be used > without licensing concerns. zsh's _git is BSD-licensed. It depends what part of the tests you want to use. Many of the tests were developed by me, so I own the copyright. I pushed the branch to my repository: https://github.com/felipec/git-completion/blob/zsh-system/test/completion-zsh-system.t 32 tests fail, 38 pass. Just run that script with Bash. > > So in my view it's clear the priorities of the two completions are > > very different. > > It's nothing as deliberate as that. It's more likely just that nobody > ever reported the bug whilst someone able and inclined to fix it > happened to be listening. In many cases nobody reported the bugs to the Git mailing list either. Git developers themselves find the areas of opportunity. > Also, in the specific case of «git -C», the Git maintainers probably use > that option far more often than the average zsh user does (to run their > HEAD builds against test repositories). Precisely. But I'm talking more about the speed. This is the thing is very clear Git developers care about, as they often perform tests on the Bash completion itself, and optimize it, shaving milliseconds here and there. I sent a patch to exemplify how this speed can be leveraged from Zsh's official completion, for example using __git_complete_revlist, which is extremely fast, compared to whatever the Zsh completion is doing. Yes, it probably doesn't autocomplete exactly the same list, but it's more than good enough. These are the priorities I'm talking about; mainly the compromise in completeness in order to get more usability (actually save the user's time while completing commands). Cheers. -- Felipe Contreras ^ permalink raw reply [flat|nested] 9+ messages in thread
end of thread, other threads:[~2020-11-23 18:31 UTC | newest] Thread overview: 9+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2020-11-19 16:05 git-completion 1.2 released Felipe Contreras 2020-11-21 16:03 ` Daniel Shahaf 2020-11-21 20:14 ` Bart Schaefer 2020-11-22 0:59 ` Felipe Contreras 2020-11-22 0:53 ` Felipe Contreras 2020-11-23 4:33 ` Daniel Shahaf 2020-11-23 7:49 ` Felipe Contreras 2020-11-23 15:44 ` Daniel Shahaf 2020-11-23 18:31 ` Felipe Contreras
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).