zsh-users
 help / color / mirror / Atom feed
* 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 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-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-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

zsh-users

This inbox may be cloned and mirrored by anyone:

	git clone --mirror http://inbox.vuxu.org/zsh-users

	# If you have public-inbox 1.1+ installed, you may
	# initialize and index your mirror using the following commands:
	public-inbox-init -V1 zsh-users zsh-users/ http://inbox.vuxu.org/zsh-users \
		zsh-users@zsh.org
	public-inbox-index zsh-users

Example config snippet for mirrors.
Newsgroup available over NNTP:
	nntp://inbox.vuxu.org/vuxu.archive.zsh.users


code repositories for the project(s) associated with this inbox:

	https://git.vuxu.org/mirror/zsh/

AGPL code for this site: git clone https://public-inbox.org/public-inbox.git