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

/usr/share/nano/git.nanorc uses wrong newlines in Git for Windows 2.24.1 #2429

Closed
1 task done
ToadKing opened this issue Dec 12, 2019 · 11 comments
Closed
1 task done
Milestone

Comments

@ToadKing
Copy link

ToadKing commented Dec 12, 2019

  • I was not able to find an open or closed issue matching what I'm seeing

Setup

  • Which version of Git for Windows are you using? Is it 32-bit or 64-bit?
git version 2.24.1.windows.2
cpu: x86_64
built from commit: 992f0773022527b1b0cb1e0c13aec97dd5248053
sizeof-long: 4
sizeof-size_t: 8

  • Which version of Windows are you running? Vista, 7, 8, 10? Is it 32-bit or 64-bit?
Microsoft Windows [Version 10.0.18363.476]
(64-bit)
  • What options did you set as part of the installation? Or did you choose the
    defaults?
Editor Option: VIM # NOTE: I override this in my .bash_profile to be nano
Custom Editor Path:
Path Option: Cmd
SSH Option: OpenSSH
Tortoise Option: false
CURL Option: OpenSSL
CRLF Option: CRLFAlways
Bash Terminal Option: MinTTY
Performance Tweaks FSCache: Enabled
Use Credential Manager: Enabled
Enable Symlinks: Disabled
Enable Builtin Interactive Add: Disabled
  • Any other interesting things about your environment that might be related
    to the issue you're seeing?

No

Details

  • Which terminal/shell are you running Git from? e.g Bash/CMD/PowerShell/other

Bash

nano
  • What did you expect to occur after running these commands?

No errors to appear.

  • What actually happened instead?

The message [ Mistakes in '/usr/share/nano/git.nanorc' ] appears at the bottom of the nano screen. Upon exiting nano, the following is logged to the console:

Error in /usr/share/nano/git.nanorc on line 1: Regex strings must begin and end with a " character
" not understoodare/nano/git.nanorc on line 2: Command "
" not understoodare/nano/git.nanorc on line 10: Command "
" not understoodare/nano/git.nanorc on line 15: Command "
Error in /usr/share/nano/git.nanorc on line 19: Regex strings must begin and end with a " character
" not understoodare/nano/git.nanorc on line 20: Command "
" not understoodare/nano/git.nanorc on line 23: Command "
" not understoodare/nano/git.nanorc on line 26: Command "
" not understoodare/nano/git.nanorc on line 33: Command "
" not understoodare/nano/git.nanorc on line 36: Command "
" not understoodare/nano/git.nanorc on line 42: Command "
" not understoodare/nano/git.nanorc on line 44: Command "
" not understoodare/nano/git.nanorc on line 47: Command "
" not understoodare/nano/git.nanorc on line 50: Command "
" not understoodare/nano/git.nanorc on line 51: Command "
Error in /usr/share/nano/git.nanorc on line 53: Regex strings must begin and end with a " character
" not understoodare/nano/git.nanorc on line 54: Command "
" not understoodare/nano/git.nanorc on line 57: Command "
" not understoodare/nano/git.nanorc on line 60: Command "
" not understoodare/nano/git.nanorc on line 74: Command "
" not understoodare/nano/git.nanorc on line 77: Command "
" not understoodare/nano/git.nanorc on line 80: Command "

Upon inspecting the file, it appears it has Windows-style \r\n newlines instead of Unix-style \n newlines. Changing them fixes the issue.

@rimrul
Copy link
Member

rimrul commented Dec 12, 2019

This is strange. My local /usr/share/nano/git.nanorc has the same issue. The git.nanorc in git-extra was last modified almost 2 years ago, but the Build agent updated the checksum in pkgbuild 13 days ago. @dscho could you check for an accidental local change that caused this checksum to change in 3638691 and updated the git.nanorc in the git-sdk repos, but not the git.nanorc in build-extra/git-extra?

dscho added a commit to git-for-windows/build-extra that referenced this issue Dec 12, 2019
Due to a switch to a redesigned Azure Pipeline that builds and publishes
our MINGW packages, the `git-extra` package is now built from a checkout
that uses the default `core.autoCRLF` setting of Git for Windows.

As a consequence, all files that were not marked explicitly with LF-only
line endings were changed to CR/LF line endings in the latest
`git-extra` package, including `git.nanorc` (and Nano does not like that
change, not one bit).

Let's just simplify the entire setup and tell Git that all text files
within `build-extra` are to have LF line endings.

This addresses git-for-windows/git#2429

Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
@dscho
Copy link
Member

dscho commented Dec 12, 2019

@dscho could you check for an accidental local change that caused this checksum to change in 3638691 and updated the git.nanorc in the git-sdk repos, but not the git.nanorc in build-extra/git-extra?

Surely you did not mean 3638691, but instead git-for-windows/build-extra@3638691?

I can suspect a reason: I switched to a new, more reliable (and most importantly: public) Azure Pipeline to build git-extra (and other MINGW packages): https://dev.azure.com/git-for-windows/git/_build?definitionId=32

Now, my guess is that the build-extra repository was cloned in https://dev.azure.com/git-for-windows/git/_build/results?buildId=46608 with the default core.autoCRLF=true.

And obviously I failed to inspect the resulting commits closely, and missed that change of checksums.

I pushed some commits that (hopefully) fix this and cross my fingers that https://dev.azure.com/git-for-windows/git/_build/results?buildId=47247 will work. Last time it took 11 minutes to build and publish git-extra... 🤞

@ToadKing could I ask you to open a Git Bash as administrator in the meantime and convert the git.nanorc file to Unix line endings using dos2unix?

@rimrul
Copy link
Member

rimrul commented Dec 12, 2019

Surely you did not mean 3638691, but instead git-for-windows/build-extra@3638691?

yes. That's absolutely what I meant.

@ToadKing
Copy link
Author

Yes, I've already converted the file and that fixes the issues for me.

@dscho dscho added this to the Next release milestone Dec 12, 2019
@dscho
Copy link
Member

dscho commented Dec 12, 2019

Unfortunately, the Pipeline failed a couple of times, and one of my attempts to fix it broke the final run, after the Pacman packages were published, so I had to fix things manually. The next snapshot should be fixed already.

@dscho
Copy link
Member

dscho commented Dec 13, 2019

I just merged a PR, which kicked of a snapshot build; Once that is complete, can I ask you to test with the new snapshot?

@rimrul
Copy link
Member

rimrul commented Dec 13, 2019

I've tried the snapshot installer Git-prerelease-2.24.1.windows.2.4.gb5deb24d74-64-bit.exe, nano was back in working order.

@ToadKing
Copy link
Author

Git-prerelease-2.24.1.windows.2.4.gb5deb24d74-64-bit.exe fixes the issue for me as well.

@bigguiness
Copy link

I'm having the same issue.

How to you convert the git.nanorc file? I tried using dos2unix but get a Permission denied error.

Is the git.nanorc file the only one that has the problem?

@rotelstift
Copy link

rotelstift commented Dec 13, 2019

@bigguiness
Run git bash with administrator privileges, and then run command

$ dos2unix /usr/share/nano/git.nanorc

I had the same issue and I didn't know dos2unix command.
So, your comment is so helpful for me!
Thank you!

@dscho
Copy link
Member

dscho commented Dec 13, 2019

@bigguiness alternatively, use the latest snapshot.

dscho added a commit to git-for-windows/build-extra that referenced this issue Dec 15, 2019
The startup file for GNU nano, which had been included with DOS line
endings (and therefore upset `nano`) [is now included with Unix line
endings again](git-for-windows/git#2429).

Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
@dscho dscho closed this as completed Dec 15, 2019
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