Add appendable global .gitattributes file#19
Conversation
|
This seems fairly harmless as it can't delete any labels. |
This comment has been minimized.
This comment has been minimized.
|
It works:
|
This should prevent most line-ending issues, e.g. exercism/docs#148.
| *.* text eol=lf | ||
|
|
||
| # Windows forced line-endings | ||
| /.idea/* text eol=crlf |
There was a problem hiding this comment.
Is there a reason why we need to mention IDE specific files at all? I understand the *.sln and similar MS IDE files which today are also used by their dotnet CLI, but IntelliJ config files shouldn't be necessary anywhere.
There was a problem hiding this comment.
Because contributors and maintainers will use these tools and if we don't include them, their tools will break.
There was a problem hiding this comment.
Would this make the files in the .idea directory on Linux/macOS also have CRLF line endings?
There was a problem hiding this comment.
In my opinion IDE specific files should be ignored globally and shouoldn't be in any repository at all.
Unless you enforce a specific IDE at least project wide. As far as I know, such an enforcement only exists for the Delphi, Pharo and Elisp tracks. And here the enforcement is more or less given by the nature of the languages, that no standalone compilers exist.
There was a problem hiding this comment.
In my opinion IDE specific files should be ignored globally and shouoldn't be in any repository at all.
And I don't agree. Unfortunately you need to know that you need to configure something in order for a repository to not break. And many people don't actually know how to configure something.
On top of that, it's almost impossible to override .gitattributes for "some globs", so in this case leaving editor configurations out will actively break people's environments.
There was a problem hiding this comment.
How should a git repository break things that are not intended to be part of the repository?
It is some IDE specific stuff, that should never be committed. So git will never temper with its line endings.
So how will removing this break peoples stuff?
There was a problem hiding this comment.
Because .idea isn't ignored as a folder, nor is .sln. So their repo will break, and can only unbreak if they now manually add it to the ignore (and fix line-endings, and git remove it).
Which we can't do exercism-wide, because repos that require IntelliJ or Visual Studio (not code) would require some of the files in those directories to be commited.
I absolutely agree with you that in an ideal world it would be not in here at all.
There was a problem hiding this comment.
Again, I expect IDE files to be ignored on the users host, or not to be commited at all. I accept that there are *.sln files, for the dotnet tracks, its just how their tooling works, though there is not a single track that requires .idea beeing in the repository. So why should it ever be commited?
For erlang I would not accept a PR containing them. And if accidental commit breaks the committers IDE, I do not care. It was their fault to commit files that weren't intended for comitting.
A .idea/ in a global git-ignore file, will ignore the folder and anything within it. Adding this to a global ignore file would be the solution for the problem.
There was a problem hiding this comment.
And if there will ever be a track requiring .idea in their repository, they still can add the necessary attributes to their repo-append.
| *.doc diff=astextplain | ||
| *.DOC diff=astextplain | ||
| *.docx diff=astextplain | ||
| *.DOCX diff=astextplain | ||
| *.dot diff=astextplain | ||
| *.DOT diff=astextplain | ||
| *.pdf diff=astextplain | ||
| *.PDF diff=astextplain | ||
| *.rtf diff=astextplain | ||
| *.RTF diff=astextplain |
There was a problem hiding this comment.
Will we really ever have those binary document files within a git repository?
There was a problem hiding this comment.
docs and some of the website repos do, tracks might. I don't see why we would leave it out if we know how to not break those files if they're ever present.
It doesn't cost us anything to have these on there, right?
| *.png binary | ||
| *.jpg binary | ||
| *.jpeg binary | ||
| *.gif binary | ||
| *.ico binary | ||
| *.mov binary | ||
| *.mp4 binary | ||
| *.mp3 binary | ||
| *.flv binary | ||
| *.fla binary | ||
| *.swf binary | ||
| *.gz binary | ||
| *.zip binary | ||
| *.7z binary | ||
| *.ttf binary | ||
| *.eot binary | ||
| *.woff binary | ||
| *.pyc binary | ||
| *.pdf binary | ||
| *.ez binary | ||
| *.bz2 binary | ||
| *.swp binary |
There was a problem hiding this comment.
This selection of binary formats again seems very broad to me, why should there ever be such files within a repository?
I can accept images, but vidoe?
There was a problem hiding this comment.
I have a few practice exercises in mind about simulating something. Those may benefit from having a video visualisation of the expected result, so I don't think it's impossible that there'll ever be video files somewhere on Exercism (though they'd probably be added via git lfs or in a separate repo)
This comment has been minimized.
This comment has been minimized.
| *.* text eol=lf | ||
|
|
||
| # Windows forced line-endings | ||
| /.idea/* text eol=crlf |
There was a problem hiding this comment.
Would this make the files in the .idea directory on Linux/macOS also have CRLF line endings?
| # Custom for Visual Studio | ||
| *.cs diff=csharp | ||
| *.sln merge=union | ||
| *.csproj merge=union | ||
| *.vbproj merge=union | ||
| *.fsproj merge=union | ||
| *.dbproj merge=union |
There was a problem hiding this comment.
I'm wondering if this should be in the global .gitattributes or just in an appends file in the C#/F#/VB repos.
|
@SaschaMann linked to https://rehansaeed.com/gitattributes-best-practices/ which contains the following: # Force bash scripts to always use lf line endings so that if a repo is accessed
# in Unix via a file share from Windows, the scripts will work.
*.sh text eol=lfThis is taken from the dotnet/corefx |
|
My take on this, is that there's no downside to being over-zealous in this file. While I get it's in some ways annoying to have files listed that shouldn't be in git (and that most-likely won't get to our git repos), I don't see a downside to being overtly cautious. So while adding project files, or IDE files to this may feel unnecessary, if someone starts a track for "CsharpScript" and that reuses `. csproj, I'd rather not have to remember to add this as an append, and if someone does upload an PDF because they feel its important (e.g. a licence), I'd rather that other maintainer who tries to use that repo later doesn't have to fight with line-endings as part of that. Even if we would rather they found a way to not upload the PDF. ie, I'd rather be proactive in this, rather than reactively trying to police all commits to ensure that such files don't get added. So laying any general thoughts on what should/shouldn't be here in an ideal world, are there any downsides from a functional perspective to adding this file everywhere? |
@ErikSchierboom Want to add this as a GitHub "suggestion" in some appropriate spot? |
|
@ErikSchierboom Do you want to add the batch-equivalent listed in that post too? |
Done.
🤷 I find that scenario for more unlikely than the shell based one, so I would be fine with adding it or not having it. |
I don't care much either, but there seem to be a fair amount of |
Co-authored-by: Erik Schierboom <erik_schierboom@hotmail.com>
Maybe just add it then? |
|
GitHub's UI is being annoying, need to check manually that the newlines at the end are correct once it's ready to be merged (@ErikSchierboom it's the same issue as we had before) |
|
I'm off today, but I'll check tomorrow @SaschaMann! |
|
@SaschaMann It looked like the newline was indeed missing, so I've added it in 0182cd6. I've checked with both vi and a bit of F# code, and both seem to confirm that there is now an empty line at the end of the file. |
|
I want to resurrect this issue, as I've been bitten by this again last week. The following tracks already have a ./prolog/.gitattributes Before we can merge this, we should consider what to do with these tracks. Do we want to do a diff and have the missing lines in an appends file? Do we just want to move it to an appends file (leading to duplicate entries)? |
|
How does this solve the hard to understand appends system? There should not be duplicate entries. Some tooling will complain when you do and it's hard to debug. |
Well, hopefully it is full-fledged enough for most tracks not having to bother with an appends file.
Right. We should then do something a bit more involved for those tracks then. |
|
It's a small enough list to go through a diff mnanually and append it to the bottom. The challenge is .gitattributes is evaluated from top to bottom, I think, so overrides below others work differently than above them. |
|
Does anyone have any new ideas for resolving this? Or should we abandon it? |
|
I think we should still pursue this. I have to get a diff from the existing .gitattributes files. |
|
Recent problem with a track that does have a If we do this, do we also need CI to enforce that a PR does not add the wrong kind of line endings? |
6 participants
This should prevent most line-ending issues, e.g. exercism/docs#148.
@SleeplessByte