Git Gui shows spaces at the end of line highlighted with red; how can I turn off this feature?
Apparently (see comments) Git Gui uses the same control knob here as plain command-line git, namely the core.whitespace setting, as described in the git config documentation:
core.whitespace
A comma separated list of common whitespace problems to notice. git diff will use color.diff.whitespace to highlight them, and git apply --whitespace=error will consider them as errors. You can prefix - to disable any of them (e.g. -trailing-space):
blank-at-eol treats trailing whitespaces at the end of the line as an error (enabled by default).
space-before-tab treats a space character that appears immediately before a tab character in the initial indent part of the line as an error (enabled by default).
indent-with-non-tab treats a line that is indented with space characters instead of the equivalent tabs as an error (not enabled by default).
tab-in-indent treats a tab character in the initial indent part of the line as an error (not enabled by default).
blank-at-eof treats blank lines added at the end of file as an error (enabled by default).
trailing-space is a short-hand to cover both blank-at-eol and blank-at-eof.
cr-at-eol treats a carriage-return at the end of line as part of the line terminator, i.e. with it, trailing-space does not trigger if the character before such a carriage-return is not a whitespace (not enabled by default).
tabwidth=<n> tells how many character positions a tab occupies; this is relevant for indent-with-non-tab and when Git fixes tab-in-indent errors. The default tab width is 8. Allowed values are 1 to 63.
(I'm not sure how Git Gui allows you to modify the config, or whether you must do that from a command line. Presumably you want -trailing-space in this case, or maybe just -blank-at-eol.)
Related
From the Xerces documention on setNewLine, “However, Xerces-C++ always uses LF when this property is set to null since otherwise automatic translation of LF to CR-LF on Windows for text files would result in such files containing CR-CR-LF. If you need Windows-style end of line sequences in your output, consider writing to a file opened in text mode or explicitly set this property to CR-LF.” That statement makes no sense to me.
https://xerces.apache.org/xerces-c/apiDocs-3/classDOMLSSerializer.html#a56882d2fe0b4a0ecb1b3968febbcf4a3
Why an auto conversion of line endings results in a duplicate CR is beyond me. I do not understand why that would ever be reasonable. I have tried changing the code to explicitly set the line ending to CR-LF as described in the documentation and that does not work. I still end up with xml files that have CRCRLF as the line ending and then I have to manually remove the duplicate CR with a text editor such as notepad++.
Asking this question is my last resort. I try to run "make all" and I get the error
Makefile:457: *** missing separator. Stop.
on the the line with cloc (second line).
linecount:
cloc --read-lang-def=$(PROJECT).cloc \
src/$(PROJECT) include/$(PROJECT) tools examples \
python matlab
I changed spaces to tabs both on that line and inside the file $(PROJECT).cloc. However, the error persists. And it only appears on that line. I am at a loss.
Use vim or vi to open makefile then write :set list it will show you all the spaces and tabs. Tabs are ^I and line endings are ^$ . Make sure your indentation is always with tabs instead of spaces or even 4 spaces. 4 spaces doesn't make a tab in makefile you should use tabs for indentation. You can make this with other editors as well.
You can do the same thing as in Alperen's answer with nano by opening the makefile and using the key combination alt+shift+p to enable whitespace display where tabs will be represented by a > character and spaces by a . character. This will indicate what make is 'seeing' at the beginning of that line, it may not be a tab character despite what it may seem.
What mistake am I making in the steps I'm following?
I've edited files in repo Alpha on my local box. I then realized I wanted those changes in a different repo Bravo that is also on my local box. I tried this:
c:/repos/alpha/>git diff --cached > mypatch.txt
I then copy the patch file to the other repo location and type this:
c:/repos/bravo/>git apply mypatch.txt
If the shell I used for the diff and apply was powershell or "Git CMD", then the second command makes the error:
fatal: unrecognized input
If instead I use the "Git Bash" shell to execute the two commands, then I get a different error:
5109e.patch:19: trailing whitespace.
IL.DataUsageGB,
warning: 1 line adds whitespace errors.
I then try to apply the changes more carefully with the following command:
$ git apply --reject --whitespace=fix mypatch.txt
From this I get a dump of numerous errors. Example:
error: while searching for:
);
GO
-- Anchor table ------------------------------------------------------------
-------------------------------------------
-- IL_InvoiceLine table (with 33 attributes)
----------------------------------------------------------------------------
-------------------------------------------
IF Object_ID('dbo.IL_InvoiceLine', 'U') IS NULL
CREATE TABLE [dbo].[IL_InvoiceLine] (
error: patch failed: scripts/bi/sql/Unified_ODS_Schema.sql:302
The branch in repo Alpha and the corresponding branch in repo Bravo both come from the same origin and both have a git status that report "up to date" with the upstream. In other words, the branches are identical except for the staged changes that exist on Alpha. I am expressly avoiding a push/pull with the origin.
Suggestions?
TL;DR
There's nothing wrong, and you can completely ignore the warning. You don't need --reject or --whitespace=fix, but if you do want to use the latter, use it without the former.
Longer
If the shell I used for the diff and apply was powershell ...
This winds up writing the output as Unicode (through some mechanism I cannot describe properly since I don't "do" Windows). You'd have to filter that back to UTF-8 or ASCII to get it to apply.
If instead I use the "Git Bash" shell to execute the two commands, then I get a different error:
5109e.patch:19: trailing whitespace.
IL.DataUsageGB,
warning: 1 line adds whitespace errors.
That's not really an error, that's a warning. It means that your original patch adds a blank before an end-of-line. By default, git apply calls this an "error" but it really means "warning". It's meant to alert you to the fact that there's an invisible character on the line(s) in question, which you may not have intended. (Or maybe you did! For instance, in some Markdown formats, ending a line with two blanks inserts a paragraph break. See aslo Git ignore trailing whitespace in markdown files only.)
What constitutes a "whitespace error" (which really should be "whitespace annoyance" or "whitespace warning" or "whitespace glitch" everywhere, rather than "error") is configurable. By default git diff will highlight such whitespace glitches. While I cannot quite show it here, imagine the - line is in red and the + line is in green and that <space> represents a trailing blank:
- blah blah
+ blah foo blah<space>
This space would be highlighted in red, to make it stand out as a "whitespace error" (which I would call a whitespace glitch or annoyance or warning, but as long as we are using Git we should understand what the phrase "whitespace error" means here).
With --whitespace=fix, git apply will find the things it considers to be whitespace errors and determine whether it can fix them automatically by:
stripping trailing whitespace
removing some space-before-tab spaces
fussing with CRLF vs LF-only
If it can fix them, it will. This includes applying the patch even if the context does not quite match up but can be made to do so by this kind of fussing, so it's more than just "removing trailing whitespace in the added lines".
I've been commiting/pushing to a public repo and finding that one commit where I may have changed less than 100 lines results in a commit with 1000 changes.
For example, I may change several lines in a method in AppDelegate.
The resulting problem is something that looks like that following:
To better showoff what whitespace issues might be occurring here is another area of unwanted commitage:
You have formatted the code and now git treats your whitecaps as changes.
Set this flag to ignore any white spaces changes
core.whitespace
Git comes preset to detect and fix some whitespace issues.
It can look for six primary whitespace issues – three are enabled by default and can be turned off, and three are disabled by default but can be activated.
git config --global core.whitespace <...>
core.whitespace
core.whitespace
A comma separated list of common whitespace problems to notice. git diff will use color.diff.whitespace to highlight them, and git apply --whitespace=error will consider them as errors.
You can prefix - to disable any of them (e.g. -trailing-space):
blank-at-eol
treats trailing whitespaces at the end of the line as an error (enabled by default).
space-before-tab
treats a space character that appears immediately before a tab character in the initial indent part of the line as an error (enabled by default).
indent-with-non-tab
treats a line that is indented with space characters instead of the equivalent tabs as an error (not enabled by default).
tab-in-indent
treats a tab character in the initial indent part of the line as an error (not enabled by default).
blank-at-eof
treats blank lines added at the end of file as an error (enabled by default).
trailing-space is a short-hand to cover both blank-at-eol and blank-at-eof.
cr-at-eol treats
a carriage-return at the end of line as part of the line terminator, i.e. with it, trailing-space does not trigger if the character before such a carriage-return is not a whitespace (not enabled by default).
tabwidth=
tells how many character positions a tab occupies; this is relevant for indent-with-non-tab and when Git fixes tab-in-indent errors. The default tab width is 8. Allowed values are 1 to 63
Well, the problem is any command involving manipulations with patches refuses to work in the following manner:
<stdin>:16: trailing whitespace.
<stdin>:17: trailing whitespace.
<stdin>:18: trailing whitespace.
<stdin>:19: trailing whitespace.
<stdin>:20: trailing whitespace.
warning: recount: unexpected line:
fatal: corrupt patch at line 101
(As a result?) Interactive mode doesn't work.
Tried to tweak core.whitespace with no success.
Please help me to resolve this annoying issue.
This message usually comes from the pre-commit hook when its checking for non-ascii content.
The sample pre-commit hook may be doing a check for trailing whitespace.
To disable it, look in .git/hooks and make sure the files there are not executable.
###git-stripspace
Read
https://www.kernel.org/pub/software/scm/git/docs/git-stripspace.html