namsh, good idea to test with a simple repo, it saves a lot of useless investigation :) What you describe is really weird, and I want to understand why vimagit behaves so slowly. Could you give me some information about your configuration? Like: * vim version * git version * what terminal do you use + version * anything else which seems relevant for you
Also, could you try this branch of vimagit: https://github.com/jreybert/vimagit/tree/dev/test_filetype Open magit in your simple repository, it should be slow as before. Then, from the magit buffer, type; :set ft=txt and try to refresh. Is it still slow? Thanks for your report! Jérôme On Wednesday, November 4, 2015 at 10:47:52 AM UTC+1, SungHyun Nam wrote: > 2015-11-04 오후 5:24에 Jérôme Reybert 이(가) 쓴 글: > > Hello namsh, > > > >> Personally I cannot live without 'git add -p'. > >> And I want to say vimagit is a great plugin for this workflow. > >> Thanks for your powerful plugin. > > > > Great to hear that! > > > >> But, it is too slow for me. > > > > There is some improvements to do around that. I have some on > > going branches about performances, but some of them introduce > > some tedious and error prone logics that ask some work. > > > > Anyway, you may want to try the branch next to test a first > > performance improvement feature. > > > >> But, ':Magit' took 5 seconds to show the status. > >> CR on Makefile took 5 seconds. > >> 'S' on Makefile took 5 seconds..... > > > > For your specific problem, may I ask you to report it on github? > > It will be easier to me to track him for next release. > > OK. > > > One question anyway: do you have untracked files or stashes in > > your repository? If so, could you try the branch next to check > > that it solves your performance issue? > > To test vimagit, I just edited Makefile in a clean work tree. > > $ git status -sb > ## master...origin/master [ahead 1] > M Makefile > > 'next' branch took about 3 seconds for :Magit, CR and S. > > The repo I tested had 89MiB of git objects. > And the repo includes 12 submodules if it relevant. > > I made a empty repo and commit a 1 line file. And then add > another 1 line. Now :Magit took about 2 seconds for this simple > repo. > > Because my PC (+VirtualBox) is so slow, I think I can use vimagit now. > > >> I run several time, so the timing is not for cold start. > >> For me, this plugin needs at least 5 seconds to do something. > >> If this is not expected, should I check something? > > > > vimagit display logic is really simple today. It will cache in > > internal vim variables the whole diffs in your repository, > > including untracked files; for example, if your repository has a > > build directory which is not ignored, vimagit will cache diff > > for each files in your build directory, which may take a long > > time. In branch next, it won't cache diffs for "closed" file/dir > > (which is the default when you open the vimagit buffer). > > Thanks, > namsh -- -- You received this message from the "vim_use" maillist. Do not top-post! Type your reply below the text you are replying to. For more information, visit http://www.vim.org/maillist.php --- You received this message because you are subscribed to the Google Groups "vim_use" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. For more options, visit https://groups.google.com/d/optout.
