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
Related
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".
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.)
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
Since I installed OS X Mavericks, the result of the command git diff is rendering ESC[xxx characters like this:
ESC[1mdiff --git a/console/org.linkedin.glu.console-webapp/decorate-grails-methods-plugin/plugin.xml b/console/org.linkedin.glu.console-webapp/decorate-grails-methods-plugin/plugin.xmlESC[m
ESC[1mindex 3b65cf1..0ca5d7e 100644ESC[m
ESC[1m--- a/console/org.linkedin.glu.console-webapp/decorate-grails-methods-plugin/plugin.xmlESC[m
ESC[1m+++ b/console/org.linkedin.glu.console-webapp/decorate-grails-methods-plugin/plugin.xmlESC[m
ESC[36m## -15,14 +15,14 ##ESC[m ESC[mThe purpose of this plugin is to decorate various grails methods.ESC[m
This used to render properly prior to installing Mavericks. I have no clue what is different so any help in troubleshooting would be much appreciated.
Note that the pager used is less since when I hit h I get the following:
SUMMARY OF LESS COMMANDS
Commands marked with * may be preceded by a number, N.
Notes in parentheses indicate the behavior if N is given.
Do you have a LESS environment variable set? You can check using:
env | grep LESS
or:
echo $LESS
If so, you want to make sure the R option is in there. That allows the ANSI escape sequences to pass through unscathed, and they'll be rendered as colors in the terminal.
Just for reference, I use this:
export LESS=eFRX
This works:
git config --global core.pager "less -r"
Try "less -R" (big "R")
This worked for me:
git config core.pager 'less -R'
Example:
Without "-R" you just get raw ESC control codes:
With "-R" you get the actual color:
"less -R" vs. "less -r"
-R (big R) seems to be the safer version of -r (small r). So that's why I prefer the big R version.
Quote from man less:
-r or --raw-control-chars
Causes "raw" control characters to be displayed. The default is to display control characters using the caret notation; for example, a control-A (octal 001) is displayed as "^A". Warning: when the -r option is used, less cannot keep track of the actual appearance of the screen (since this depends on how the screen responds to each type of control character). Thus, various display problems may result, such as long lines being split in the wrong place.
-R or --RAW-CONTROL-CHARS
Like -r, but only ANSI "color" escape sequences are output in "raw" form. Unlike -r, the screen appearance is maintained correctly in most cases. ANSI "color" escape sequences are sequences of the form:
ESC [ ... m
where the "..." is zero or more color specification characters For the purpose of keeping track of screen appearance, ANSI color escape sequences are assumed to not move the cursor. You can make less think that characters other than "m" can end ANSI color escape sequences by setting the environment variable LESSANSIENDCHARS to the list of characters which can end a color escape sequence. And you can make less think that characters other than the standard ones may appear between the ESC and the m by setting the environment variable LESSANSIMIDCHARS to the list of characters which can appear.
The global pager configuration option within git, just sends the output stream to the more or less commands. You can get rid of the escape characters within this output by setting the global configuration option to either:
git config --global core.pager "more -R"
To continue using more as your pager or
git config --global core.pager "less -R"
To continue using less as your pager
Another alternative is to eliminate git's "colorizing" of output by doing something like
$ git config --global color.ui false
See git help config for details.
Reference: unix.stackexchange: How to colorize output of git?
You change use the option -R Repaint the screen to remove all the buffered input.
export LESS="$LESS -R"
I had faced similar issues. My Output for LESS was:
LESS=-iMPM--?f%f--:--.?lb lines %lt-%lb.?L of %L.?pB (%pB%).
LESSOPEN=||/usr/bin/lesspipe.sh %s
Tried executing below, but it did not resolve the issue-
git config --global color.ui auto true
The issue was resolved using -
export LESS=eFRX