39

What business is it of whatever VCS I'm using to worry about what I put in my files? I don't get what the point here is. Is git version control or syntax checker?

Bjorn
  • 69,215
  • 39
  • 136
  • 164
  • See also http://stackoverflow.com/a/30803980/6309, to differentiate between "old" whitespace error introduced by previous commits, and new ones, introduced by current staged code for the next commit. – VonC Jun 12 '15 at 13:16

6 Answers6

36

It is because one of the very common uses for Git is sending patch series via email. Trailing spaces cause trouble in email, and are thus usually stripped out, which means any trailing spaces will be lost in the process of sending the patch via email and applying it. This in turn means that if there are trailing spaces on lines in the repo, but not in the patch being applied, you may get spurious conflicts, or extra changes that weren't intended, when applying a patch.

This pre-commit hook used to be enabled by default, but is no longer. It seems I have misremembered; it was never deliberately enabled by default. As others have pointed out, this has always been a sample pre-commit hook; it used to be disabled by not giving it the execute bit, but that's something that can get screwed up fairly easily (for instance, running under Cygwin on Windows), so in newer versions of Git (since over a year ago) the samples have been disabled by being named pre-commit.sample. You can delete or move your .git/hooks/pre-commit to prevent this hook from executing if you don't like the behavior. You should also update your Git to something more recent, as this has been fixed for quite a while.

Brian Campbell
  • 322,767
  • 57
  • 360
  • 340
  • Yeah, I figured that was the case, but I wanted to make sure I clarified as I looked through the Git history and realized that I had been incorrect. – Brian Campbell Oct 18 '09 at 16:31
  • It is pretty easy mistake to make as the man page says: `The default pre-commit hook, when enabled, catches introduction of lines with trailing whitespaces and aborts the commit when such a line is found.` So it is the default, but the default isn't enabled, making it more of an example. – jmh Oct 20 '12 at 00:07
  • Oh my dear lord, using git for "sending patches via email"? Isn't git about remote repositories and sending changes between them? Instead I'd say that whitespace errors are generally bad because they make diffs look silly. – gyorgyabraham Mar 25 '13 at 16:07
  • 1
    @gyabraham Sending patches via email is how code review works for many projects, such as the Linux kernel which Git was originally written for. Many open source project maintainers will only pull from the repositories of trusted sub-project maintainers, and all other patches go via email, where they can be seen and commented on publicly before applying them. – Brian Campbell Mar 25 '13 at 19:23
  • 1
    I was exporting a repository from a Linux server to a Mac using Samba (it's a long story!). By default, Samba sets the execute bit on *everything* which was causing the sample pre-commit hook to fire. I fixed the problem by renaming "hooks" to "sample-hooks" since I don't use any hook for this repo. – kbro Feb 02 '17 at 13:06
  • an example of we can do to fix the file would be helpful. no mention of that yet. i tried dos2unix, but that didnt cover it. I guess we can just go to the end of every line and delete the extra spaces, or you can craft a substitute replace for them. – blamb Nov 19 '19 at 18:50
12

Git doesn't care at all. The example pre-commit hook does a whitespace check as a demonstration of how to write a hook, but it's not enabled by default; you have to make it executable for it to do anything.

hobbs
  • 223,387
  • 19
  • 210
  • 288
5

Why? Because trailing whitespace is easily lost, leading to spurious changes and to not applied patches (because of whitespace change). It is a matter of conforming to programming style.

That said it is a question of pre-commit hook: you can edit it, or disable it, or configure trailing whitespace (perhaps for some kinds of files only) to be not considered an error.

The pre-commit hook should be disabled by default, but older versions (pre 1.6.0) used to install them turned off by having executable permissions turned off, which might not work on non-UNIX filesystems like FAT; from 1.6.0 they are installed turned off (disabled) by having '.sample' suffix appended.

Jakub Narębski
  • 309,089
  • 65
  • 217
  • 230
  • @apphacker: The checks used by default pre-commit hook is about *sending patches via email*, not so much about programming style. – Jakub Narębski Oct 18 '09 at 18:40
  • +1 for Bjorn (about not needing developers to enforce their idea of style, my pet peeve in that area is GCC) – Nicholaz Mar 30 '13 at 14:32
3

As hobbs wrote, 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.

One possible way that the hooks may have gotten enabled is that the executable bit may have gotten set if you were moving your repo around on a FAT-formatted flash drive.

Phil
  • 4,767
  • 1
  • 25
  • 21
3

You can bypass this by using the --no-verify switch, see http://git-scm.com/docs/githooks

Walinton Cambronero
  • 31
  • 1
1

It's not a matter of VCS trying to tell you what good programming style is. It is a matter that trailing whitespace are a bad thing to them, because trailing whitespace can be seen as a useless modification by the VCS.

How so?

Imagine you have a line like this:

puts "Hello World"^M^M^M

Where each "^M" is a trailing whitespace (put there to simplify).

Another developer accidentally changes this like to this:

puts "Hello World"^M^M

The VCS will see this as a change. A useless one that does not interferes with the code at all, but a change. This kind of change can even be pointed by the VCS as a conflict (which is something that should be avoided whenever possible). Besides, it pollutes your history without need.

YuriAlbuquerque
  • 2,178
  • 1
  • 11
  • 19