vim uses unix style EOL which breaks plugin usage and conflicts with native vim #364
Comments
|
Isn't this a duplicate? |
|
Did some digging and found #272 |
|
More like "help wanted": #272 (comment) |
|
Well, trying to fix using instructions in #272: The error is command not found. There is Any ideas? |
|
You need to install pacman -S binutils(I thought that the Git for Windows SDK already installed that by default.) |
|
I fixed the comment as well as the wiki page about Package management. |
|
Sorry, I'm very new to windows git sdk and msys, so I can't handle it correctly paul@nb-paulu MSYS /usr/src/MSYS2-packages/vim (master) paul@nb-paulu MSYS /usr/src/MSYS2-packages/vim (master) paul@nb-paulu MSYS /usr/src/MSYS2-packages/vim (master) |
|
Have a look in the |
|
Please note that upstream just updated vim to a newer version. You might want to verify first that the newer version still exposes the problem (call |
When sharing Windows' home directory, we have to expect that the `.vimrc` file can have DOS line endings. Let's be lenient about this, as well as all other input we get, and just handle CR/LF as well as LF line endings. We still behave as before, otherwise. This fixes git-for-windows/git#272 and git-for-windows/git#364 Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
When sharing Windows' home directory, we have to expect that the `.vimrc` file can have DOS line endings. Let's be lenient about this, as well as all other input we get, and just handle CR/LF as well as LF line endings. We still behave as before, otherwise. This fixes git-for-windows/git#272 and git-for-windows/git#364 Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
When sharing Windows' home directory, we have to expect that the `.vimrc` file can have DOS line endings. Let's be lenient about this, as well as all other input we get, and just handle CR/LF as well as LF line endings. We still behave as before, otherwise. This fixes git-for-windows/git#272 and git-for-windows/git#364 Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
|
As of |
Replaces git-for-windows#367, which used the upstream commits directly. This instead includes a merge commit onto `vfs-2.32.0` so we can move forward even if the upstream version is modified. This integrates the sparse-index with `git status`. There is a LOT of code here, and much of it makes future changes (git-for-windows#361 and git-for-windows#364) much simpler than they would be otherwise. This merges into `features/sparse-index` which is intended to be released as an experimental release. The goal of reviewing this PR is to find "good enough for a limited release to dogfooders" and not the same scrutiny of upstream. In particular, I am currently looking for an issue with directory/file conflicts at the sparse-checkout boundary. They don't reveal themselves until `git checkout`, and only in very rare cases that won't affect our dogfooders.
…se-index This follows git-for-windows#374 and git-for-windows#361 to complete the necessary functionality for the sparse-index experimental release. This does not include the behavior changes requested upstream. The request is about how `git add` currently ignores changes that match a tracked path outside of the sparse-checkout definition. However, this is an established behavior of Git, so we don't need to change it for our dogfooders.
Vim shipped with git uses unix style EOL.
Git uses windows style EOL (it can be configured, but convenient way is to use windows styIe on Windows).
if user want to use plugin manager (for example vim-plug) with shipped vim, it will break vim experience:
vim uses git to checkout plugin, git uses CRLF, vim can't load checkouted plugin.
The text was updated successfully, but these errors were encountered: