Is there any way to make Git ignore space-related modifications or line breaks?

Question

I have a refactoring craze. If I see something missing or with line breaking excess, the first thing I do is fix.

I’m using Visual Studio Code in a project and I use GIT to do version control. These files that I usually give a line break or space to fix some formatting end up filling the notification tab of modifications in the project.

I’d like to know if there’s any way to make GIT ignore insignificant changes like line breaking or adding spaces (not between one character or another, but white space).

I mean, I want GIT to disregard modifications like these when listing files to commit with git status.

Updating:

There is a blessed being who works on the same project that I love to use 2 spaces, while I like to use 4 spaces per tab.

I was wondering if there’s a way to ignore this also through GIT.

Answer 1

I mean, I want GIT to disregard modifications like these when listing files for the commit with git status.

I understand that you would like this behavior after doing some kind of merge with a branch in which the standardization of spaces used is different from your.

Although it is possible to do this "git status" by ignoring the space differences, using a git diff (untested example: git diff -w | git apply --cached --ignore-whitespace), Solving your problem starts when branches merge.

Unfortunately it is not possible to simply skip file spaces. A file with 2 spaces is different from a file with 4 spaces inside git, as they generate different hashs. When git sees this situation in a merge, it remains for it to try to merge or show the problem (in conflict form).

However, you can make it resolve this merge for you automatically by "ignoring" this space problem. Note that in this case you’re not really ignoring, you’re just telling git what to do in this case.

For this, at the time of the merge, use the flag -Xignore-space-change:

git merge -s recursive -Xignore-space-change

The -Xignore-space-change here is explained as follows, by documentation, how it affects your merge:

• If its version only introduces space changes to the line, its version is used.
• If your version introduces space changes but its version includes a substantial amount of changes, its version is used.
• Otherwise, the merge follows normally.

Finally

In addition, if your friend likes 2 spaces and you like 4 spaces, and you can’t reach an agreement, you can consider a change to tabulation per tab, then each of you chooses the size of the tab by the IDE, better solving this question of how they prefer to view the code.

Answer 2

I found the answer in Stack Overflow in English in this link.

Below the translation.

It seems you need more control and standardization of the development process. The one who commits changes must be the same person who modifies the files. Or at least the committer must know exactly what has changed.

Carefully examine the output of git diff and use the flag-w to ignore spaces. There are also options to show differences within a line. See * Differences within a line * below.

Note that you won’t be able to tell git to skip the space changes when confirming. I suggest using Gitx (I prefer the "brotherbard" Fork), which allows you to interactively discard pieces before committing.

Use descriptive messages when confirming. For example, if a file has been split, say so. Make your commits small. If you find yourself writing long commit messages, split the commit into smaller parts. That way, when you examine the logs long after, it will make more sense what has changed.

** Differences within a line **

Git has some ability to show "word" differences in a single line. The simplest way is to just use the git diff --color-words.

However, I like to customize the meaning of a "word" using the setting diff.wordRegex. I also like the format plain-diff because it shows more clearly where the differences are (inserts parentheses around the changes in addition to using colors).

Commando:

    git diff --word-diff=plain

along with this in my configuration:

[diff]
       wordRegex = [[:alnum:]_]+|[^[:alnum:]_[:space:]]+

This regex treats these as "words":

• consecutive sequences of alphanumerics and underlining
• consecutive sequences of non-alphanumeric, unassembled and non-spaced (good for detecting operators)

You must have a recent version of git to usewordRegex. See your man page git-config to see if the option is listed.

UPGRADE

If you use the git mv to rename a file (which is preferable to use another tool or the operating system to rename), you can see git detecting the rename. I highly recommend committing a renaming independently of any editing on the file contents. That’s because git doesn’t store the fact that you renamed it - it uses a heuristic based on how much the file was changed to guess if it was the same file. The less you change it during renaming, the better.

If you slightly changed the contents of the file, you can use the parameter -C to thegit diff and git log to try harder to detect copies and rename. Add a percentage (e.g., "-C75%") to make git more supportive of the differences. The percentage represents the similarity of the content to be considered a match.

I hope I’ve helped.

Answer 3

Access to the premises ~/.gitconfig

Adding the alias below

[alias]
    addse=!sh -c 'git diff -U0 -w --no-color "$@" | git apply --cached --ignore-whitespace --unidiff-zero' -

whenever add utilize

 git addse seuarquivo.txt

Documentation of how to create alias https://git.wiki.kernel.org/index.php/Aliases#Aliases