Repository properties about nzbget HOT 8 CLOSED

Did you perform line ending normalization after adding the .gitattributes file?

from nzbget.

Did you perform line ending normalization after adding the .gitattributes file?

I hope to did it right this time.

from nzbget.

@hugbug, sadly it looks like you took a step backwards in the follow up changes you made. Specifically commit 85bf40fd9dcdf23221e020bc763a46edcc899a11.

You set: * text eol=lf. This has a few issues:

• Everything is forcibly treated as text unless you explicitly add a line to treat it as not text (-text). This means if you missed some binary file types, those are now treated as text.
• Furthermore, this adds some overhead because if you ever introduce new binary types into your repository, you have to remember to go add a line for that type to .gitattributes.
• On all platforms, since you have done * eol=lf, you are specifying that Git will always check out files using LF. This is even on Windows.

I think the way you had it before was much better. Ideally you want to use the OS native line endings for files on checkout (e.g. you will get LF on linux for text files, and CRLF on windows for those same text files). Git automatically determines whether or not to use CRLF or LF based on text=auto and the value of core.eol in your git configuration (defaults to native). This gives the user the flexibility to choose the line endings they want in their working copy, while still performing the necessary line ending normalization on check-in.

Some files (like *.vcproj) you want to always be CRLF, which is why eol=crlf exists. You already take care of these it looks like, so that's good.

I'm happy to work with you directly to set this up if you'd like. I have a lot of experience with it.

from nzbget.

Thank you for your comments.

Ideally I would like the things to work as before in svn where the line endings were the same for all platforms. There is no need to use different endings on different platforms actually. For the most part Windows works OK with LF (Visual C++ can edit and compile them without issues). Few Windows files must be CRLF however.

The source code distribution archive is made with make diston Linux. This archive is for all users including Windows users. This archive is the preferred way for users to get the source code of NZBGet, not git clone. That's why I have to setup line endings on POSIX to use CRLF for Windows files, for example README-Windows.txt must be CRLF even on Linux because it can be put into the distribution archive anytime.

Ideally I would like the same line endings on all platforms.
is it possible? I understand * text eol=lfwas wrong. I thought it would effect only text files. I'd like to keep the binary/text file detection active but to use LF for all text files by default, unless CRLF was explicitly defined for specific files.

from nzbget.

You're right that LF works for the majority of tools and file types on Windows. You can override where necessary, which you already do. My suggestion was made on the basis of flexibility. It doesn't hurt to use the configuration of core.eol either, even if this means for certain users it checks out using CRLF.

For your purposes you could set core.eol to lf:

$ git config --global core.eol lf

And for * text=auto you would get LF in your working copy.

Unfortunately there is no way to do what you're wanting to do. At first glance you might think this would work:

* text=auto eol=lf

One might think that this performs automatic text/binary detection and for those found as text, force them to be LF on checkout. This however forces EOL conversion to LF for binary files as well. There is no way to do this in Git at the moment. More information here:
http://stackoverflow.com/questions/29435156/what-will-text-auto-eol-lf-in-gitattributes-do

Right now the best option is to just use * text=auto and for files that function just fine regardless of line ending (i.e. you have no special requirements on EOL), rely on the core.eol setting and * text=auto. For those files you need to force to a specific EOL, do so as an override (Seems you already take care of this).

Remember that forcing Git to behave like SVN did is going to create a lot of headache for you for little or no benefit in most cases.

Also please note that it is very confusing to expect users to run make dist to perform a clone. The de facto and understood method of cloning a repository is and always will be to do a git clone directly. There is nothing wrong with doing this. I can guarantee users will do this in most cases:

$ git clone ssh://your/repo.git
$ cd repo
$ ./configure
$ sudo make install

You should expect this and try to make this work as much as possible.

from nzbget.

Here is what I recommend you set your .gitattributes to:

* text=auto

# Use CRLF for certain Windows files.
*.vcproj                        eol=crlf
*.sln                           eol=crlf
*.nsi                           eol=crlf
*.bat                           eol=crlf
README-WINDOWS.txt              eol=crlf
windows/package-info.json       eol=crlf
windows/resources/resource.h    eol=crlf
windows/resources/nzbget.rc     eol=crlf
lib/par2/README                 eol=crlf

# Configure GitHub's language detector
lib/*               linguist-vendored linguist-language=C++
webui/lib/*         linguist-vendored
Makefile.in         linguist-vendored
configure           linguist-vendored
config.sub          linguist-vendored
aclocal.m4          linguist-vendored
config.guess        linguist-vendored
depcomp             linguist-vendored
install-sh          linguist-vendored
missing             linguist-vendored
configure.ac        linguist-vendored=false
Makefile.am         linguist-vendored=false

Explanation:

• Doing eol=crlf implies text, so you don't have to do text eol=crlf, doing eol=crlf is the same thing.
• I removed explicit setting of binary on those files that are obviously binary. Git will already detect these as binary for you, so it reduces clutter in the file.
• Tabbed stuff over so it's nicer and easier to read

Remember that by default, files not overridden will use CRLF on checkout in Windows, and LF on checkout in POSIX. If you have files that do not function properly under this scheme across platforms, add another override for them (i.e. specify eol=lf or eol=crlf for those files below * text=auto).

from nzbget.

Great, I changed the file as you suggested with two minor changes:

*.nsi eol=crlf

replaced with nzbget-setup.nsi eol=crlf to avoid questions "what is .nsi?" :) I will not have other .nsi-files.

lib/par2/README eol=crlf

removed that line. No one really cares about libpar2's README anyway and it also looks like an oversight of libpar2 author to have this file in CRLF format whereas all others are in LF format.

Please let me know if everything is OK before I close the issue.

Also please note that it is very confusing to expect users to run make dist to perform a clone.

No, I don't expect them to do that. When you go to NZBGet's download page or releases page you'll find various binary packages for different platforms and in addition a source distribution package (old name nzbget-15.0.tar.gz, new name nzbget-15.0-src.tar.gz). It's me who doing make distand uploads the created archive. Users only download it. Of course users can do git clone instead but in that case they'll get the latest development version (unless they take further steps to switch to certain tag) which isn't meant for average users who just want to compile the latest stable or testing release.

from nzbget.

Looks great man, just make sure to re-run line ending normalization once more to make sure your final .gitattribute changes take effect. If you don't, you'll end up with poisoned diffs when those files change later.

$ git rm --cached -r .
$ git reset --hard
$ git status

Commit any changes that show up.

Also thanks for your explanation of make dist. It was my misunderstanding, apparently. Also users can easily clone your repo at a tag like so:

$ git clone -b v6.0 ssh://[email protected]/your/repo.git

Just as an example. You maybe could also use this method in your scripts too. Up to you, this is just a tip / pointer.

Thanks for making the changes! Hopefully this setup will work for you long-term.

from nzbget.