[ANN]: vimagit, a new way to use git within vim

classic Classic list List threaded Threaded
15 messages Options
Reply | Threaded
Open this post in threaded view
|

[ANN]: vimagit, a new way to use git within vim

Jérôme Reybert
Believe it or not, but emacs has an excellent plugin ;) . This is an interface to git, a plugin named Magit[1]. Its creator designed a unique and really efficient workflow with git. IMO, Magit is more than just a plugin to use git within an editor, this is a new way to use git.

I felt very frustrated during two years, stuck with git gui (or git add -p ?!), although my officemate staged like crazy with Magit. Actually, before he showed me Magit, I was quite happy with what I had. But once I discovered Magit, that was too late. Then, I had two choices, start using emacs, or develop a Magit-like interface for vim. I chose the latter!

> But hey, Tim Pope himself created fugitive, what's wrong with you?

I do not blame fugitive quality, this is a very good plugin. But I don't like much what fugitive offers for staging. As long as your changes belong to one file,
:Gstatus<CR>do]cdo]c]cdo:w^WkC
does the job. But if you have changes among multiple files, visualize them globally and stage some of them is a pain to me with fugitive.

Anyway, features like Gdiff or Gblame will stay key features in my workflow. I believe that fugitive, vim-gitgutter and vimagit are complementary.

For all these reasons, I started to develop vimagit[2]. It is 100% inspired^Wcopied from Magit, from the display to the key bindings, trying to reproduce the same workflow. In a first time, I will only focus on stage part. In that sense, vimagit has reached an important step with version 1.4. IMO, it now embeds the minimal feature requirements to be a usable git staging tool, and not just a toy. I use it for my professional projects.

You can see a complete description on github[2], and a demo on asciinema[3].

Looking forward for feedback!

Jérôme

[1]: https://github.com/magit/magit
[2]: https://github.com/jreybert/vimagit
[3]: https://asciinema.org/a/28761

--
--
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 [hidden email].
For more options, visit https://groups.google.com/d/optout.
Reply | Threaded
Open this post in threaded view
|

Re: [ANN]: vimagit, a new way to use git within vim

David Woodfall
>Believe it or not, but emacs has an excellent plugin ;) . This is an interface to git, a plugin named Magit[1]. Its creator designed a unique and really efficient workflow with git. IMO, Magit is more than just a plugin to use git within an editor, this is a new way to use git.
>
>I felt very frustrated during two years, stuck with git gui (or git add -p ?!), although my officemate staged like crazy with Magit. Actually, before he showed me Magit, I was quite happy with what I had. But once I discovered Magit, that was too late. Then, I had two choices, start using emacs, or develop a Magit-like interface for vim. I chose the latter!
>
>> But hey, Tim Pope himself created fugitive, what's wrong with you?
>
>I do not blame fugitive quality, this is a very good plugin. But I don't like much what fugitive offers for staging. As long as your changes belong to one file,
>:Gstatus<CR>do]cdo]c]cdo:w^WkC
>does the job. But if you have changes among multiple files, visualize them globally and stage some of them is a pain to me with fugitive.
>
>Anyway, features like Gdiff or Gblame will stay key features in my workflow. I believe that fugitive, vim-gitgutter and vimagit are complementary.
>
>For all these reasons, I started to develop vimagit[2]. It is 100% inspired^Wcopied from Magit, from the display to the key bindings, trying to reproduce the same workflow. In a first time, I will only focus on stage part. In that sense, vimagit has reached an important step with version 1.4. IMO, it now embeds the minimal feature requirements to be a usable git staging tool, and not just a toy. I use it for my professional projects.
>
>You can see a complete description on github[2], and a demo on asciinema[3].
>
>Looking forward for feedback!
>
>Jérôme
>
>[1]: https://github.com/magit/magit
>[2]: https://github.com/jreybert/vimagit
>[3]: https://asciinema.org/a/28761

Thanks. This works well.

-Dave

--
--
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 [hidden email].
For more options, visit https://groups.google.com/d/optout.
Reply | Threaded
Open this post in threaded view
|

Re: [ANN]: vimagit, a new way to use git within vim

Justin M. Keyes
In reply to this post by Jérôme Reybert
On Tue, Oct 27, 2015 at 7:09 AM, Jérôme Reybert <[hidden email]> wrote:
> Believe it or not, but emacs has an excellent plugin ;) . This is an interface to git, a plugin named Magit[1]. Its creator designed a unique and really efficient workflow with git. IMO, Magit is more than just a plugin to use git within an editor, this is a new way to use git.
>
> I felt very frustrated during two years, stuck with git gui (or git add -p ?!), although my officemate staged like crazy with Magit. Actually, before he showed me Magit, I was quite happy with what I had. But once I discovered Magit, that was too late. Then, I had two choices, start using emacs, or develop a Magit-like interface for vim. I chose the latter!
>
>> But hey, Tim Pope himself created fugitive, what's wrong with you?
>
> I do not blame fugitive quality, this is a very good plugin. But I don't like much what fugitive offers for staging. As long as your changes belong to one file,
> :Gstatus<CR>do]cdo]c]cdo:w^WkC
> does the job. But if you have changes among multiple files, visualize them globally and stage some of them is a pain to me with fugitive.

Did you try the "D" command on the "Changes to be committed:" line in
a fugitive :Gstatus window? That shows a unified diff of _all_ staged
changes in _all_ files.

> Anyway, features like Gdiff or Gblame will stay key features in my workflow. I believe that fugitive, vim-gitgutter and vimagit are complementary.
>
> For all these reasons, I started to develop vimagit[2]. It is 100% inspired^Wcopied from Magit, from the display to the key bindings, trying to reproduce the same workflow. In a first time, I will only focus on stage part. In that sense, vimagit has reached an important step with version 1.4. IMO, it now embeds the minimal feature requirements to be a usable git staging tool, and not just a toy. I use it for my professional projects.
>
> You can see a complete description on github[2], and a demo on asciinema[3].
>
> Looking forward for feedback!
>
> Jérôme
>
> [1]: https://github.com/magit/magit
> [2]: https://github.com/jreybert/vimagit
> [3]: https://asciinema.org/a/28761

vimagit looks like a nice effort. But after watching the video, I
don't see what's very different from using the `D` command on the
"Changes to be committed:" line in a fugitive :Gstatus window. Are you
sure you explored all of fugitive's functionality (some of which is a
bit subtle)?

Thanks

Justin M. Keyes

--
--
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 [hidden email].
For more options, visit https://groups.google.com/d/optout.
Reply | Threaded
Open this post in threaded view
|

Re: [ANN]: vimagit, a new way to use git within vim

Jérôme Reybert
Hi Justin,

> Did you try the "D" command on the "Changes to be committed:" line in
> a fugitive :Gstatus window? That shows a unified diff of _all_ staged
> changes in _all_ files.

I did know the 'D' command on files, but I did not know it was possible to perform "D" (or even "p") command on "Changes not staged for commit:" or "Changes to be committed:" lines. That is a nice feature indeed.

> vimagit looks like a nice effort. But after watching the video, I
> don't see what's very different from using the `D` command on the
> "Changes to be committed:" line in a fugitive :Gstatus window. Are you
> sure you explored all of fugitive's functionality (some of which is a
> bit subtle)?

D command on "Changes not staged for commit:" line seems to be a read only feature (which is not not the case on file lines BTW). Then you can visualize your whole repository changes to be staged, but you must go to another view to stage them. You have at least choices:
1- navigate through your modified/new/deleted files with Gstatus, type D, go to diff window, choose your changes with dp/do, switch again to Gstatus window to select another file.
2- use 'git add --patch' with fugitive, by file or for all files (typing 'p' on "Changes not staged for commit:" line).

I feel that both method are not very efficient:
1- You must switch among windows a lot, and you don't see the overall changes.
2- I see two downsides with 'git add --patch'
  - this is a one way process, I you forgot to stage something, or if you you staged something you don't want, you must restart git add --patch.
  - you are limited to stage by hunk.

About the video, I made it intentionally short with a simple use case. Maybe it does not highlight well the vimagit features. What vimagit brings new is:

* it is more user friendly than git add --patch, because you see what you are staging immediately, and it is more interactive.
* you can stage part of hunks (by visual selecting lines and stage selection with 'S', marking lines with 'M' and stage with 'S', or adding single lines with 'L').

You may argue that it is only two points. But it makes a fresh new workflow to work with git. Then, maybe you won't like it, but give vimagit a try, and let me know how you feel with this workflow.

Anyway, thanks for your feedback.

Jérôme

--
--
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 [hidden email].
For more options, visit https://groups.google.com/d/optout.
Reply | Threaded
Open this post in threaded view
|

Re: [ANN]: vimagit, a new way to use git within vim

glts
On Monday, November 2, 2015 at 11:11:45 AM UTC+1, Jérôme Reybert wrote:

> > Did you try the "D" command on the "Changes to be committed:" line in
> > a fugitive :Gstatus window? That shows a unified diff of _all_ staged
> > changes in _all_ files.
>
> I did know the 'D' command on files, but I did not know it was possible to perform "D" (or even "p") command on "Changes not staged for commit:" or "Changes to be committed:" lines. That is a nice feature indeed.
>
> > vimagit looks like a nice effort. But after watching the video, I
> > don't see what's very different from using the `D` command on the
> > "Changes to be committed:" line in a fugitive :Gstatus window. Are you
> > sure you explored all of fugitive's functionality (some of which is a
> > bit subtle)?
>
> D command on "Changes not staged for commit:" line seems to be a read only feature (which is not not the case on file lines BTW). Then you can visualize your whole repository changes to be staged, but you must go to another view to stage them. You have at least choices:
> 1- navigate through your modified/new/deleted files with Gstatus, type D, go to diff window, choose your changes with dp/do, switch again to Gstatus window to select another file.
> 2- use 'git add --patch' with fugitive, by file or for all files (typing 'p' on "Changes not staged for commit:" line).
>
> I feel that both method are not very efficient:
> 1- You must switch among windows a lot, and you don't see the overall changes.
> 2- I see two downsides with 'git add --patch'
>   - this is a one way process, I you forgot to stage something, or if you you staged something you don't want, you must restart git add --patch.
>   - you are limited to stage by hunk.
>
> About the video, I made it intentionally short with a simple use case. Maybe it does not highlight well the vimagit features. What vimagit brings new is:
>
> * it is more user friendly than git add --patch, because you see what you are staging immediately, and it is more interactive.
> * you can stage part of hunks (by visual selecting lines and stage selection with 'S', marking lines with 'M' and stage with 'S', or adding single lines with 'L').
>
> You may argue that it is only two points. But it makes a fresh new workflow to work with git. Then, maybe you won't like it, but give vimagit a try, and let me know how you feel with this workflow.
It's always good to hear other people talk about the tools I use every
day. Another titbit here:

After seeing the episode about fugitive.vim's :Gdiff on Vimcasts.org I
have altogether stopped using git add --patch.

Open a diff with :Gdiff or D in the status window, then stage or unstage
individual lines of your work copy/index copy with :diffget and
:diffput. It's like git add --patch but interactive and as precise as
you like.

That episode is at http://vimcasts.org/e/33. I've never looked back.


--
David

--
--
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 [hidden email].
For more options, visit https://groups.google.com/d/optout.
Reply | Threaded
Open this post in threaded view
|

Re: [ANN]: vimagit, a new way to use git within vim

Jérôme Reybert
David,

> It's like git add --patch but interactive and as precise as
> you like.

I may have missed something, but I think I already stated why Gdiff was not an optimal git stage workflow.

Once again, fugitive is a good plugin, but guys at emacs magit team have designed a powerful git workflow. It is a personal opinion, but once I discovered this workflow, I definitely wanted it with vim.

Jérôme

--
--
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 [hidden email].
For more options, visit https://groups.google.com/d/optout.
Reply | Threaded
Open this post in threaded view
|

Re: [ANN]: vimagit, a new way to use git within vim

SungHyun Nam-2
2015-11-03 오후 8:52에 Jérôme Reybert 이(가) 쓴 글:

> David,
>
>> It's like git add --patch but interactive and as precise as
>> you like.
>
> I may have missed something, but I think I already stated why
> Gdiff was not an optimal git stage workflow.
>
> Once again, fugitive is a good plugin, but guys at emacs magit
> team have designed a powerful git workflow. It is a personal
> opinion, but once I discovered this workflow, I definitely
> wanted it with vim.

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.

But, it is too slow for me.

    $ time git status
    On branch master
    ...

            modified:   Makefile

    no changes added to commit (use "git add" and/or "git commit -a")

    real 0m0.578s
    user 0m0.220s
    sys 0m0.303s

    $ time git diff --stat
     Makefile | 1 +
     1 file changed, 1 insertion(+)

    real 0m0.625s
    user 0m0.216s
    sys 0m0.358s

But, ':Magit' took 5 seconds to show the status.
CR on Makefile took 5 seconds.
'S' on Makefile took 5 seconds.....

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?

Regards,
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 [hidden email].
For more options, visit https://groups.google.com/d/optout.
Reply | Threaded
Open this post in threaded view
|

Re: [ANN]: vimagit, a new way to use git within vim

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.

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?

> 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).

Thank you for your report, it will help to improve vimagit.

Jérôme

--
--
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 [hidden email].
For more options, visit https://groups.google.com/d/optout.
Reply | Threaded
Open this post in threaded view
|

Re: [ANN]: vimagit, a new way to use git within vim

SungHyun Nam-2
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 [hidden email].
For more options, visit https://groups.google.com/d/optout.
Reply | Threaded
Open this post in threaded view
|

Re: [ANN]: vimagit, a new way to use git within vim

Jérôme Reybert
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 [hidden email].
For more options, visit https://groups.google.com/d/optout.
Reply | Threaded
Open this post in threaded view
|

Re: [ANN]: vimagit, a new way to use git within vim

SungHyun Nam-2
2015-11-05 오전 7:25에 Jérôme Reybert 이(가) 쓴 글:

> 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?

I think further debugging should be discussed on other channel.
I will open new issue on github/vimagit for this.

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 [hidden email].
For more options, visit https://groups.google.com/d/optout.
Reply | Threaded
Open this post in threaded view
|

Re: [ANN]: vimagit, a new way to use git within vim

Eike Rathke-3
In reply to this post by Jérôme Reybert
Hi Jérôme,

On Tuesday, 2015-10-27 04:09:49 -0700, Jérôme Reybert wrote:

> Looking forward for feedback!

I tried it, works with smaller repos, takes its time with large repos,
but completely fails if invoked in a directory that contains a small
repo but hundred thousand files in subdirectories that are not part of
the repo. It ate all memory and still wasn't ready after hours. Let it
run a day or so and at the end there was

"magit-playground" [Not edited] --No lines in buffer--
Error detected while processing function magit#show_magit..magit#update_buffer..magit#state#update..magit#state#add_file
..magit#state#add_file..magit#state#add_file..magit#utils#is_binary:
line    1:
E33: No previous substitute regular expression
Press ENTER or type command to continue

Does it by chance scan all subdirectories for files not added? Could
that be turned off?

  Eike

--
OpenPGP/GnuPG encrypted mail preferred in all private communication.
Key "ID" 0x65632D3A - 2265 D7F3 A7B0 95CC 3918  630B 6A6C D5B7 6563 2D3A
Better use 64-bit 0x6A6CD5B765632D3A here is why: https://evil32.com/
Care about Free Software, support the FSFE https://fsfe.org/support/?erack
Use LibreOffice! https://www.libreoffice.org/

--
--
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 [hidden email].
For more options, visit https://groups.google.com/d/optout.

signature.asc (836 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: [ANN]: vimagit, a new way to use git within vim

Jérôme Reybert
Hi Eike,

thanks for your report. Actually, I have ongoing work around selective default display and maximum diff buffering/display before it slow down the vimagit process.

Anyway, could you please open an issue on github? It'll be easier to track this issue for both of us.

Thanks,

Jérôme

On Monday, November 9, 2015 at 11:03:58 AM UTC+1, Eike Rathke wrote:

> Hi Jérôme,
>
> On Tuesday, 2015-10-27 04:09:49 -0700, Jérôme Reybert wrote:
>
> > Looking forward for feedback!
>
> I tried it, works with smaller repos, takes its time with large repos,
> but completely fails if invoked in a directory that contains a small
> repo but hundred thousand files in subdirectories that are not part of
> the repo. It ate all memory and still wasn't ready after hours. Let it
> run a day or so and at the end there was
>
> "magit-playground" [Not edited] --No lines in buffer--
> Error detected while processing function magit#show_magit..magit#update_buffer..magit#state#update..magit#state#add_file
> ..magit#state#add_file..magit#state#add_file..magit#utils#is_binary:
> line    1:
> E33: No previous substitute regular expression
> Press ENTER or type command to continue
>
> Does it by chance scan all subdirectories for files not added? Could
> that be turned off?
>
>   Eike
>
> --
> OpenPGP/GnuPG encrypted mail preferred in all private communication.
> Key "ID" 0x65632D3A - 2265 D7F3 A7B0 95CC 3918  630B 6A6C D5B7 6563 2D3A
> Better use 64-bit 0x6A6CD5B765632D3A here is why: https://evil32.com/
> Care about Free Software, support the FSFE https://fsfe.org/support/?erack
> Use LibreOffice! https://www.libreoffice.org/
--
--
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 [hidden email].
For more options, visit https://groups.google.com/d/optout.
Reply | Threaded
Open this post in threaded view
|

Re: [ANN]: vimagit, a new way to use git within vim

Jérôme Reybert
Hi Eike,

> > Does it by chance scan all subdirectories for files not added? Could
> > that be turned off?

it was not supposed to, but it was. I believe it is fixed in last release 1.4.2. Let me know if it is OK for you.

Jérôme

--
--
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 [hidden email].
For more options, visit https://groups.google.com/d/optout.
Reply | Threaded
Open this post in threaded view
|

Re: [ANN]: vimagit, a new way to use git within vim

Eike Rathke-3
Hi Jérôme,

On Wednesday, 2015-11-11 14:36:14 -0800, Jérôme Reybert wrote:

> > > Does it by chance scan all subdirectories for files not added? Could
> > > that be turned off?
>
> it was not supposed to, but it was. I believe it is fixed in last release 1.4.2. Let me know if it is OK for you.

Seems to work now, thanks.

  Eike

--
OpenPGP/GnuPG encrypted mail preferred in all private communication.
Key "ID" 0x65632D3A - 2265 D7F3 A7B0 95CC 3918  630B 6A6C D5B7 6563 2D3A
Better use 64-bit 0x6A6CD5B765632D3A here is why: https://evil32.com/
Care about Free Software, support the FSFE https://fsfe.org/support/?erack
Use LibreOffice! https://www.libreoffice.org/

--
--
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 [hidden email].
For more options, visit https://groups.google.com/d/optout.

signature.asc (836 bytes) Download Attachment