Comments (27)
This is now supported in the newest version.
from neogit.
Keybindings definitly still have to be adjusted. Initially I just copied all of the keybindings from magit to not have to think about this.
Automatically commiting when using :wq
is quite tricky, but I'll try to see how we could do this.
from neogit.
I think vim-fugitive's implementation is here:
https://github.com/tpope/vim-fugitive/blob/36f9211da2e07c5c40d378cdf6360e6abd9495ac/autoload/fugitive.vim#L4687
Whether anyone but tpope can understand it is another question...
from neogit.
Maybe could be done with BufWritePost
/BufUnload
/BufDelete
/QuitPre
autocommands?
The big question would be how to distinguish :q[!]
from :wq
.
from neogit.
The big question would be how to distinguish :q[!] from :wq.
That is also why I didn't implement this in the beginning. I think there should be a way to do this.
from neogit.
Not quite. What they do is, they set the $GIT_EDITOR env var to this:
https://github.com/tpope/vim-fugitive/blob/36f9211da2e07c5c40d378cdf6360e6abd9495ac/autoload/fugitive.vim#L2633-L2638
This is basically just a script that only exits when a certain $FUGITIVE.exit
file is written OR a $FUGITIVE.edit
file no longer exists, both of which i believe happen here:
https://github.com/tpope/vim-fugitive/blob/36f9211da2e07c5c40d378cdf6360e6abd9495ac/autoload/fugitive.vim#L2427-L2453
The .exit seems to handle aborting when vim is exited, while the .edit file looks like a file to synchronize asynchronous jobs over in general, where the commit dialog is one of them.
from neogit.
On that note, I actually prefer the way magit does it's... magic... in that regard. They use emac's remote capabilities to set $GIT_EDITOR
to spawn an emacsclient
that connects back to the running instance, opening the buffer to .git/COMMIT_EDITMSG
there.
Now, vim has a very similar feature (check :help client-server
), however most of the documentation seems to be outdated for neovim (--remote
is not a valid option to nvim
) and while there are RPC clients for ruby, python, js and whatnot, the internal lua api vim.api
does not give remote capabilities.
The best shot for this, sans writing a client in a different language, seem to be a set of remote_
vimscript functions.
from neogit.
On that note, I actually prefer the way magit does it's... magic... in that regard. They use emac's remote capabilities to set
$GIT_EDITOR
to spawn anemacsclient
that connects back to the running instance, opening the buffer to.git/COMMIT_EDITMSG
there.Now, vim has a very similar feature (check
:help client-server
), however most of the documentation seems to be outdated for neovim (--remote
is not a valid option tonvim
)
No, but nvr
(https://github.com/mhinz/neovim-remote) is a drop-in replacement and the official way until --remote
is re-implemented in the future. (I believe that's what fugitive uses for neovim?)
from neogit.
@clason I don't think we should depend on an external executable for this. Requiring users to install a separate program just feels wrong.
from neogit.
I know about nvr
; I'm not entirely against using it, but pulling in a non-plugin dependency and having a transient dependency on python as well "just for a nicer keybinding" seems awkard at best.
That being said, since the original topic is about
The big question would be how to distinguish :q[!] from :wq.
Do we have to at all? I mean, all the solutions we discussed basically come down to "let git make the decision". But git does not care how the file was saved, afaik it just checks if there is content; the commit is aborted only if there is no commit message.
I think we could just keep our approach of managing the commit buffer ourselves and implement the same logic.
from neogit.
We could make it so that writing the buffer commits the changes.
I don't think you would write the buffer if you don't want to commit with the provided message anyways right?
Example:
:wq
commits
:w
commits
:q
aborts the commit
from neogit.
@clason I don't think we should depend on an external executable for this. Requiring users to install a separate program just feels wrong.
I don't know; it's an official neovim recommendation to install this, and other plugins (like vimtex) that need remote capabilities are happy to require it. So I don't see this as a big deal.
But if you don't need it, even better, of course!
from neogit.
We could make it so that writing the buffer commits the changes.
So basically we commit on BufWritePost
? Could be a bit counter-intuitive, but I can definitely see it work if we communicate that clearly enough.
from neogit.
That was my initial thought as well, but then I thought "maybe people have muscle memory and :w
partial messages expecting to be able to continue editing before committing?"
from neogit.
If you do that, you could also wipe the buffer on :w
so that people don't keep editing a message after it's been committed ;)
from neogit.
maybe people have muscle memory and :w partial messages expecting to be able to continue editing before committing?
Yeah I'm worrying about that too; I know I'm one of those people 😅 Personally I'd just commit on BufUnload
and abort the commit if the commit message is still empty at that point.
Now that I think about it, if we want to be fancy, we could just set a flag on the buffer at BufWritePost
so we know for certain the buffer has been written to at BufUnload
. (We might not want to do that when operating with a pre-filled commit message; think amending or reword)
from neogit.
That was my thought as well; set a flag on BufWritePost
, check that on BufUnload
to either go ahead with or abort the commit.
The only question is whether BufWritePost
fires on :wq
before BufUnload
(which it should, right?)
from neogit.
(Leaves open the possibility that someone writes some text, :w
s, then changes their mind and spams undo
followed by :q
...)
from neogit.
The only question is whether BufWritePost fires on :wq before BufUnload (which it should, right?)
From the docs:
BufUnload Before unloading a buffer, when the text in
the buffer is going to be freed.
After BufWritePost.
Before BufDelete.
from neogit.
Closing this because I think this issue is done.
from neogit.
Is there a way to remap keys in the NeogitCommitPopup?
from neogit.
@kevintraver you could write a filetype plugin.
What do you want to remap?
from neogit.
It would be cool if mapped to Commit (c)
from neogit.
@kevintraver you can remap c
to <c-c><c-c>
in the filetype plugin.
from neogit.
Awesome! Thanks
from neogit.
Another question: Is it possible to easily jump between staged / unstaged? Is there a key command for this?
from neogit.
You could try to use {
and }
of vim itself, but I don't think we support this yet.
from neogit.
Related Issues (20)
- [Nightly] Add option to disable the commit diff view window HOT 2
- Inline status diff highlighting (and overall config) HOT 3
- Autorefresh not working after writing a file? HOT 4
- improve handling of user@host:repo.git and git://host/repo parsing
- Add file/directory to .gitignore HOT 2
- [Nightly] Error occurs when opening Neogit window HOT 1
- Disable context higlight HOT 1
- Remove the `Commands: mappings` message in commit editor HOT 1
- Add support for add --patch HOT 2
- `split` and `split_above` behave same HOT 2
- Allow running `:Neogit $popup` with pre-populated flags HOT 3
- A lua api to open Commit view HOT 2
- neogit leaves behind another empty buffer every time its open HOT 3
- Support neovim 0.10 in master branch HOT 3
- Toggling and then switching windows makes it impossible to toggle again HOT 1
- Allow `show_staged_diff` to open in a vertical split HOT 1
- un staged files showing folded without filename by default HOT 6
- Latest commit broke with `attempt to call field 'system' (a nil value)` HOT 4
- `ZZ`/`ZQ` shortcuts for rebase message editor HOT 1
- Neogit doesn't work anymore with latest commit and default config HOT 1
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from neogit.