What does “1 line adds whitespace errors” mean when applying a patch?

I’m editing some markdown files of a cloned remote repository, and wanted to test creating and applying patches from one branch to another. However, every time I make any change at all, I get the following message during git apply:

0001-b.patch:16: trailing whitespace.
warning: 1 line adds whitespace errors.

(This is happening on my Mac, and I don’t know where the original code was created.)

  • How to trash all local git changes and revert to old commit?
  • Switch master repository
  • How to remove big files from old commits in bitbucket
  • How do I make git-svn use a particular svn branch as the remote repository?
  • How can I check if a filename in my Maven project contains certain characters (and then fail the build)?
  • Git marks entire file as conflicted when merging master into branch
  • What does the warning message mean, and do I need to care?

  • Releasing multiple Maven artifacts when using nested Git submodules
  • Undo part of unstaged changes in git
  • What happens to unsynced changes when the parent repos of a github fork is deleted?
  • Git - How do I delete files in upstream repo but not from my fork
  • Determine at which commit a file entered the master branch in git
  • How to indentify which commit introduce which changes in a octopuss merge
  • 4 Solutions collect form web for “What does “1 line adds whitespace errors” mean when applying a patch?”

    You don’t need to care.

    The warning enacts a standard of cleanliness of text files in regard to whitespace, the kind of thing that many programmers tend to care about. As the manual explains:

    What are considered whitespace errors is controlled
    by core.whitespace configuration. By default, trailing whitespaces
    (including lines that solely consist of whitespaces) and a space
    character that is immediately followed by a tab character inside the
    initial indent of the line are considered whitespace errors.

    By default, the command outputs warning messages but applies the patch.

    So, the “error” means that the change introduces a trailing whitespace, a whitespace-only line, or a space that precedes a tab. Other than that fact, there is nothing erroneous about the change, and it will apply cleanly and correctly. In other words, if you don’t care about the “incorrect” whitespace, feel free to ignore the warning or turn it off with git config apply.whitespace nowarn.

    One case when you could legitimately care is when you want to differentiate between “old” whitespase error (that you might want to keep for legacy reason) and “new” whitespace errors (that you want to avoid).

    To that effect, Git 2.5+ (Q2 2015) will propose a more specific option for whitespace detection.

    See commits 0e383e1, 0ad782f, and d55ef3e [26 May 2015] by Junio C Hamano (gitster).
    (Merged by Junio in commit 709cd91, 11 Jun 2015)

    diff.c: --ws-error-highlight=<kind> option

    Traditionally, we only cared about whitespace breakages introduced
    in new lines.
    Some people want to paint whitespace breakages on old
    lines, too. When they see a whitespace breakage on a new line, they
    can spot the same kind of whitespace breakage on the corresponding
    old line and want to say “Ah, those breakages are there but they
    were inherited from the original, so let’s not touch them for now.”

    Introduce --ws-error-highlight=<kind> option, that lets them pass
    a comma separated list of old, new, and context to specify
    what lines to highlight whitespace errors on.

    The documentation now includes:

    --ws-error-highlight=<kind>
    

    Highlight whitespace errors on lines specified by <kind> in the color specified by color.diff.whitespace.
    <kind> is a comma separated list of old, new, context.
    When this option is not given, only whitespace errors in new lines are highlighted.

    E.g. --ws-error-highlight=new,old highlights whitespace errors on both deleted and added lines.
    all can be used as a short-hand for old,new,context.

    For instance, the old commit had one whitespace error (bbb), but you can focus on the new errors only (at the end of still bbb and ccc):

    old and new shitespace errors

    (test done after t/t4015-diff-whitespace.sh)

    Because line begining with TAB istead of SPACE. Go on patch file and replace TAB with SPACE. E.g. on vim on line + from patch file type x to remove space and not remove sign + and insert space (CTRL) on eqiv to original size.

    Git Baby is a git and github fan, let's start git clone.