Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Git completion partly broken #4395

Closed
nyddogghr opened this issue Sep 24, 2015 · 16 comments
Closed

Git completion partly broken #4395

nyddogghr opened this issue Sep 24, 2015 · 16 comments

Comments

@nyddogghr
Copy link

Hi,

Firstly I don't know if the bug is specifically related to oh my zsh, but it started from my last update, so I'm posting here. Apologizes if it's not related.

So my issue is that since about a week, the completion for git checkout only works partially : for instance, if I use gb <Tab>, it shows the correct branches. But when I do gco <Tab>, it only shows a part of the branches names. Almost all of my branches are of the form user/feature_or_fix/issue_number/name_of_the_branch, and the completion only suggests the name_of_the_branch part of the branches. Here is an example :

nyddogghr/feature/MEDIA-12/create_rails_5

gb <Tab> will show the full branch name, gut gco <Tab> will only show the create_rails_5 part.
Of course, when selecting it it doesn't switch branch.

So is this an issue related to oh my zsh ? Does anyone else have this ?

Thanks for your help

@nyddogghr nyddogghr changed the title Git checkout completion partly broken Git completion partly broken Sep 24, 2015
@apjanke
Copy link
Contributor

apjanke commented Sep 24, 2015

Sounds likely to be related. I don't have it, but there was a recent change to OMZ that affected completion setup.

I'm on the current OMZ version on OS X 10.9.5. I can't reproduce. gb <Tab> and gco <Tab> both show me (local) branches with slashes in them. In addition, gco <Tab> will show remote branches with slashes in them.

[~/tmp/git-work on ⇄ master]
$ git branch nyddogghr/feature/MEDIA-12/create_rails_5
[~/tmp/git-work on ⇄ master]
$ gco
HEAD
master
nyddogghr/feature/MEDIA-12/create_rails_5

gb and gco are simple aliases in the git plugin. Maybe something's up with your completion as a result of #4383 / #3889. Are you seeing any other completion-related warnings or errors?

And what's your $fpath (echo "${(F)fpath}")? Perhaps #3889 repaired some directory on your $fpath such that now it is included in your completions, whereas before it was silently ignored, and this is changing your completion behavior.

Have a look at which _git. It'll tell you what the completion definition is, even though it won't show you where it was loaded from.

I get this, in my working configuration:

$ which _git | shasum
3fe6d1b41bb1586e146f37c619f83ba484ee1981  -

@jwadolowski
Copy link

Hey @nyddogghr,

I was in the middle of writing exactly the same issue when I saw you've just posted that.

In my case it behaved pretty much the same 2 days ago (partial branch names), but now git co <TAB> shows me individual commits instead of branch names.

git_oh-my-zsh

Last week git co <TAB> definitely worked as expected and the only change I've recently made was oh-my-zsh update.

@nyddogghr
Copy link
Author

Ok, I found the cause. From the issues you've linked, I found that removing git-extras plugin makes it work again. So yes it is related to OMZ, and more specifically to git-extras.
When removing it the branches are correctly found, but I still have extra branches (the name_of_the_feature part). gco <tab> will then show both nyddogghr/feature/rails_5 and rails_5
But I don't have this issue if after having removed the plugin, I create a branch and then try to checkout. It seems to only be present for branch already existing. Yes I do :(

I also don't have any issue with permissions, and here are the $fpath :

/home/flof/.oh-my-zsh/plugins/history-substring-search
/home/flof/.oh-my-zsh/plugins/sudo
/home/flof/.oh-my-zsh/plugins/mvn
/home/flof/.oh-my-zsh/plugins/wd
/home/flof/.oh-my-zsh/plugins/systemd
/home/flof/.oh-my-zsh/plugins/nyan
/home/flof/.oh-my-zsh/plugins/chucknorris
/home/flof/.oh-my-zsh/plugins/common-aliases
/home/flof/.oh-my-zsh/plugins/archlinux
/home/flof/.oh-my-zsh/functions
/home/flof/.oh-my-zsh/completions
/home/flof/.oh-my-zsh/plugins/history-substring-search
/home/flof/.oh-my-zsh/plugins/sudo
/home/flof/.oh-my-zsh/plugins/mvn
/home/flof/.oh-my-zsh/plugins/wd
/home/flof/.oh-my-zsh/plugins/systemd
/home/flof/.oh-my-zsh/plugins/nyan
/home/flof/.oh-my-zsh/plugins/chucknorris
/home/flof/.oh-my-zsh/plugins/common-aliases
/home/flof/.oh-my-zsh/plugins/archlinux
/home/flof/.oh-my-zsh/plugins/git-remote-branch
/home/flof/.oh-my-zsh/plugins/git
/home/flof/.oh-my-zsh/plugins/git-extras
/home/flof/.oh-my-zsh/functions
/home/flof/.oh-my-zsh/completions
/usr/local/share/zsh/site-functions
/usr/share/zsh/site-functions
/usr/share/zsh/functions/Calendar
/usr/share/zsh/functions/Chpwd
/usr/share/zsh/functions/Completion
/usr/share/zsh/functions/Completion/Base
/usr/share/zsh/functions/Completion/Linux
/usr/share/zsh/functions/Completion/Unix
/usr/share/zsh/functions/Completion/X
/usr/share/zsh/functions/Completion/Zsh
/usr/share/zsh/functions/Exceptions
/usr/share/zsh/functions/MIME
/usr/share/zsh/functions/Misc
/usr/share/zsh/functions/Newuser
/usr/share/zsh/functions/Prompts
/usr/share/zsh/functions/TCP
/usr/share/zsh/functions/VCS_Info
/usr/share/zsh/functions/VCS_Info/Backends
/usr/share/zsh/functions/Zftp
/usr/share/zsh/functions/Zle

And the which _git | shasum :

f7e81166870bbf091535cf666d510edd790f8828

@c0nscience
Copy link

I have the same issue since the last OMZ update a couple of days ago. I experience it with complex branchnames like feature/some_fancy_new_feature. Before the last update it gets completed like a breeze, but now nothing happens.

Edit:

And removing git-extras from the plugin list did fix the issue also for me, like @nyddogghr mentioned.

System:
OS X 10.10.5

@apjanke
Copy link
Contributor

apjanke commented Sep 24, 2015

I can reproduce this if I run the git-extras plugin. With that, gco <Tab> only completes commit identifiers, not branch names. (Just like @jwadolowski is talking about.)

Hmm. The git-extras plugin has not been changed in quite a while, so it wouldn't have been directly affected by the recent update.

[~/.oh-my-zsh on ⇄ master]
$ git log plugins/git-extras/git-extras.plugin.zsh | grep Date | head -5
Date:   Mon Dec 15 12:41:22 2014 +0800
Date:   Fri Jul 20 16:46:30 2012 +0200
Date:   Thu Jul 19 13:01:32 2012 +0200

Maybe this is the normal behavior of git-extras, and in your case, you had "insecure" permissions on its directory so it was being silently ignored and not actually running before, and then #3889 came along and fixed them and now git-extras is actually running.

Are there other features of git-extras which you have been using? (That will tell us if this scenario is likely, and also whether we can just ditch git-extras to resolve this.)

@nyddogghr: What system (OS, zsh, and git versions) are you on? And is that repo you're working on public, so we can try to reproduce the behavior with the exact same data set?

It's also weird that most of the OMZ plugin directories show up twice in your $fpath. That looks like what would happen if ~/.zshrc was re-sourced in a running session, or a new zsh -l subshell was launched, possibly after the git plugins were removed from the list in ~/.zshrc. Is that from a fresh terminal session? Re-running ~/.zshrc doesn't update your session to the new configuration; you need to launch a completely fresh shell session.

@benjaoming
Copy link
Contributor

I'm also experiencing this on the latest master branch. With git-extras. Switching it off fixes the issue.. but I'll miss git-extras.

No updates of zsh in trusty-backports since August 2014.

@benjaoming
Copy link
Contributor

Reverting this commit makes everything work again:

4bd6c43

@apjanke
Copy link
Contributor

apjanke commented Oct 1, 2015

This also seems to depend on the version of zsh I'm using. On OS X 10.9.5, with zsh 5.0.2, gco gives me commit IDs; with zsh 5.1.1, it gives me branch names.

[~/tmp/git-work on ⇄ master]
$ echo $ZSH_VERSION
5.0.2
[~/tmp/git-work on ⇄ master]
$ gco cc0af00
[✘ ~/tmp/git-work on ⇄ master]
$ /usr/local/bin/zsh -l
[~/tmp/git-work on ⇄ master]
$ echo $ZSH_VERSION
5.1.1
[~/tmp/git-work on ⇄ master]
$ gco
HEAD
master
nyddogghr/feature/MEDIA-12/create_rails_5
nyddogghr/feature/rails_5

Maybe git-extras is depending on the internals of zsh's _git completion function, and the recent commit was written against a newer zsh that changed _git.

What zsh version(s) are you folks running?

@apjanke
Copy link
Contributor

apjanke commented Oct 1, 2015

Oh, wait: it's not a zsh version difference. The difference for me is that my Homebrew-managed zsh uses /usr/local/share/zsh/site-functions, and I have a Homebrew-managed git installed, so it sees the _git completion provided by the git install instead of the one that comes with zsh itself.

@apjanke
Copy link
Contributor

apjanke commented Oct 1, 2015

Think I found your problem. #3408 added an override for __git_commits.

__git_commits() {
    declare -A commits
    git log --oneline -15 | sed 's/\([[:alnum:]]\{7\}\) /\1:/' | while read commit
    do
        hash=$(echo $commit | cut -d':' -f1)
        commits[$hash]="$commit"
    done
    local ret=1
    _describe -t commits commit commits && ret=0
}

This is rather different from the zsh _git's __git_commits(), which, despite its name, returns branch names if available, and not just commit identifiers.

__git_commits () {
  # TODO: deal with things that __git_heads and __git_tags has in common (i.e.,
  # if both exists, they need to be completed to heads/x and tags/x.
  _alternative \
    'heads::__git_heads' \
    'commit-tags::__git_commit_tags' \
    'commit-objects::__git_commit_objects'
}

@apjanke
Copy link
Contributor

apjanke commented Oct 2, 2015

Made a fix: #4444

@benjaoming
Copy link
Contributor

Hoping the fix will find its way soon :)

Another problem has been that gco <filename> has stopped working.

@apjanke
Copy link
Contributor

apjanke commented Oct 2, 2015

gco <filename> is also fixed in #4444. Just note that only modified files are presented as completion options, so if you're testing it, make sure you have some modified files in your repo that gco would actualy do something to.

@benjaoming
Copy link
Contributor

@apjanke yup I know :) I knew this auto completion very much in the back of my head / eyes closed / in my sleep.... when it was gone, the world started feeling strange and unfamiliar :D

@apjanke
Copy link
Contributor

apjanke commented Oct 4, 2015

This git-extras stuff is pretty neat. Thanks for introducing me to it; sorry it had to be by way of it breaking.

@benjaoming
Copy link
Contributor

Yeah, git-extras is awesome... I use git delete-branch all the time.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

5 participants