search

Sampsca / BGEE-Classic-Movies

This is a WeiDU mod that restores the 'classic' movies from the original Baldur's Gate and select movies from Baldur's Gate II to BGEE/SoD/EET. There is a new component that restores the vanilla BG1 chapter and dream screens to BGEE/SoD/EET (using the appropriate theme).
https://sampsca.github.io/ReadMe-BGEEClassicMovies.html
23 stars 4 forks source link

Much better .gitattributes .gitignore #4

Closed ALIENQuake closed 4 years ago

ALIENQuake commented 4 years ago

Those files are best practices based on years of corrections, addition and merging ideas from various sources.

ALIENQuake commented 4 years ago

@Sampsca Hi,

*/. export-ignore

It means that whenever somebody will download the repository source code az zip, all files with a dot at the beginning will not be added to Sampsca-BGEE-Classic-Movies-master.zip. This is handly to avoid questions from 'Windows Explorer' about .gitignore already exist, overwrite?

*.ahk

Sure, restored back.

.*

Files with a dot at the beginning at the top-level of the repo are ignored except explicitly specified. It also covers macOS .DS_Store crap

Why would you specify an eol for a file type you turn around and ignore?

Because some modders added one single .bat explicitly. All other test.bat files are ignored.

ehthumbs.db ehthumbs_vista.db

I see no reason to remove these.

Those are simply redundant in 2020. Those files are created only when someone who develops mod has Vista (<0.8% marketshare) and open the mod directory via it's Media Center.

temp/ tmp/ I can see how some modding styles could benefit from this. However, I can also see this being dangerous (having unintended effects) if this .gitignore file is marketed at a best-practace dorp-in configuration for modders new to git who aren't observant or who don't have a firm understanding of what this file is for.

I don't have much to say about this except no 'temp' files or directories should end up inside packages of any kind.

*.bcs text eol=lf

I have seen compelling arguments for using both this and binary here. I lean toward text eol=lf, but in either case, you are missing *.bs.

Confirmed by EE devs and real use-case, the only thing which is required is LF. Added *.bs.

git is usually very good about determining whether a file is binary or text. Only very rarely is it explicitly necessary to specify. That being the case, are these really necessary? If they are, in fact, arguably necessary, you're missing a good number of IE file formats.

Including those will protect from git changes that might be introduced later. If there are missing formats, please add them.

.ini text eol=crlf .txt text eol=crlf

Those are windows-native files. Image readme.txt created as CRLF, uploaded to git and then open via Windows 7 Notepad => file looks malformed.

.csv text eol=crlf .ps1 text eol=crlf

I guess those can be either removed completely or replaced with 'text', you call.

.gitignore text .gitattributes text *.y[a]ml text

Agreed, don't have a strong opinion on this.

backup/ I recognize that recent versions of WeiDU are no longer effected by this restriction

That's the point. If WeiDU handles the creation of the 'backup' directory correctly, there is no reason to using a sophisticated trick in order to 'ensure that WeiDU is not broken'.

I hope that things are clear now. I think that the best way now is to reject this PR and take only the parts which you desire. Or accept it and make further corrections. In any case, I will take your concerns into consideration when I will update my .git* files template.

Sampsca commented 4 years ago 
*.ini text eol=crlf
*.txt text eol=crlf

Those are windows-native files. Image readme.txt created as CRLF, uploaded to git and then open via Windows 7 Notepad => file looks malformed.

Regardless of which OS first used these file extensions, mods are now using them to allow users fine control over mod component installations rather than using READLN. See Infinity Animations for example. Users will want them to be in their native encoding. If eol is left unspecified, git should handle the eol conversions to a user's native convention automatically, correct? Unless someone has specifically configured git otherwise, I know eols are automatically adjusted when cloning a repo onto your local system, but I thought it did a similar thing when downloading releases as well.

ALIENQuake commented 4 years ago 
*.ini text eol=crlf
*.txt text eol=crlf

Those are windows-native files. Image readme.txt created as CRLF, uploaded to git and then open via Windows 7 Notepad => file looks malformed.

Regardless of which OS first used these file extensions, mods are now using them to allow users fine control over mod component installations rather than using READLN. See Infinity Animations for example. Users will want them to be in their native encoding. If eol is left unspecified, git should handle the eol conversions to a user's native convention automatically, correct? Unless someone has specifically configured git otherwise, I know eols are automatically adjusted when cloning a repo onto your local system, but I thought it did a similar thing when downloading releases as well.

Git handles eol conversion but only for its basic operation like pull/push, not for GitHub-related hosting features like 'downloading repo as zip'. On default git configuration, when you have local readme.txt/config.ini with CRLF, after pushing into online repo, CRLF will be replaced into LF. Then, when you downloading mod via 'Source code' you will get direct files from the repo => .txt/.ini files with LF that makes them unreadable on Windows. So that eol=crlf is required.

ALIENQuake commented 4 years ago

Found that .csv actually use RFC 4180 and Excel expects them to be CRLF.

Sampsca commented 4 years ago

I manually adjusted .gitattributes and .gitignore based on your suggestions. Also added more IE file formats.