Jump to content

Github modify the whole files

Recommended Posts

Hello everyone,

I'm starting this thread because I have a problem using this amazing tool. Most of the time, things go right, but sometime while I do a commit, the whole file seems to be modified.

This commit of Unfinished Business is the perfect example of what I'm talking about. Github detect that the whole file have been modified, but the only change I've made is to change @-1065 at line 1026 ("à" to "a"). I didn't touch the encoding (ANSI), nor the carriage return line feed (CR LF), the only ways I do know to do that on purpose. This file is the exact same file that I have pulled a few days ago and that have been merged (beside the cited change).

An another example on Freely Resizable Combat Log, it had happened on the readmes and the TP2. And again, I've just done some minor changes without changing any encoding or such.

It's not a big problem, but this is for sure frustrating and do not look very "professional". The author/maintainer cannot easily track the changes made.

On another subject, while we were working on Unfinished Business, Angel told me that one of the very old tra file I updated was partly encoded in multiple encoding. How to detect that ? I'm just using Notepad ++, and locally I can only detect a single encoding with it. How to be sure a file is encoded the right way and do not contain any other encoding, beside force-convert anything that I edit ?

Edit : Posted this in the wrong sub, Modding Q&A would have been a better spot. Sorry.

Edited by Jazira
Link to comment

Here, without the whitespace changes:

https://github.com/Jazira33/UnfinishedBusiness/commit/cca8721e00439c557d39ff7da925eacefeef4164?w=1 (you get the same if you pass -w to git log)

So yeah, the EOL characters got changed. Git has a setting where it can force this, but of course if it isn't/wasn't used consistently, one can have mixed ending files in the repo.

Encodings: sounds silly. I'd just resave the file and see if there's a git diff. If not, everything is fine, otherwise it will contain all the mangled lines, after which you can reset the file and try to figure it out (latin1?).

Link to comment

There is a git option that defines how line endings are handled. You can check it with this console command:

git config --get core.autocrlf

On Windows it should be set to "true" (unless you know what you're doing), so that text files are checked out with cr/lf (windows-style) and committed with lf (unix-style).

You can find more info here: https://git-scm.com/book/en/v2/Customizing-Git-Git-Configuration#_formatting_and_whitespace

Link to comment
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

  • Create New...