1. 14 Dec, 2018 1 commit
    • Derrick Stolee's avatar
      .gitattributes: ensure t/oid-info/* has eol=lf · fc767afe
      Derrick Stolee authored
      The new test_oid machinery in the test library requires reading
      some information from t/oid-info/hash-info and t/oid-info/oid.
      The logic to read from these files in shell uses built-in "read"
      command, which leaves CR at the end of these text files when they
      are checked out with CRLF line endings, at least when run with bash
      shipped with Git for Windows.  This results in an unexpected value
      in the variable these lines are read into, leading the tests to
      Mark them to be checked out always with the LF line endings.
      Signed-off-by: 's avatarDerrick Stolee <dstolee@microsoft.com>
      Signed-off-by: 's avatarJunio C Hamano <gitster@pobox.com>
  2. 12 Nov, 2018 1 commit
  3. 29 Aug, 2018 1 commit
  4. 27 Apr, 2018 3 commits
  5. 10 May, 2017 1 commit
    • Johannes Schindelin's avatar
      Fix build with core.autocrlf=true · 00ddc9d1
      Johannes Schindelin authored
      On Windows, the default line endings are denoted by a Carriage Return
      byte followed by a Line Feed byte, while Linux and MacOSX use a single
      Line Feed byte to denote a line ending.
      To help with this situation, Git introduced several mechanisms over the
      last decade, most prominently the `core.autocrlf` setting.
      Sometimes, however, a single setting is incorrect, e.g. when certain
      files in the source code are to be consumed by software that can handle
      only LF line endings, while other files can use whatever is appropriate
      for the current platform.
      To allow for that, Git added the `eol` option to its .gitattributes
      handling, expecting every user of Git to mark their source code
      Bash assumes that line-endings of scripts are denoted by a single Line
      Feed byte. Therefore, shell scripts in Git's source code are one example
      where that `eol=lf` option is *required*.
      When generating common-cmds.h, the Unix tools we use generally operate on
      the assumption that input and output deliminate their lines using LF-only
      line endings. Consequently, they would happily copy the CR byte verbatim
      into the strings in common-cmds.h, which in turn makes the C preprocessor
      barf (that interprets them as MacOS-style line endings). Therefore, we
      have to mark the input files as LF-only: command-list.txt and
      Quite a bit belatedly, this patch brings Git's own source code in line
      with those expectations by setting those attributes to allow for a
      correct build even when core.autocrlf=true.
      This patch can be validated even on Linux, by using this cadence:
      	git config core.autocrlf true
      	rm .git/index && git stash
      	make -j15 DEVELOPER=1
      Signed-off-by: Johannes Schindelin's avatarJohannes Schindelin <johannes.schindelin@gmx.de>
      Reviewed-by: 's avatarJonathan Nieder <jrnieder@gmail.com>
      Signed-off-by: 's avatarJunio C Hamano <gitster@pobox.com>
  6. 07 Jul, 2016 1 commit
  7. 30 Nov, 2011 1 commit
  8. 06 Jan, 2010 1 commit
  9. 21 Jun, 2009 1 commit
    • Nanako Shiraishi's avatar
      .gitattributes: CR at the end of the line is an error · e2f6331a
      Nanako Shiraishi authored
      When a CR is accidentally added at the end of a C source file in the git
      project tree, "git diff --check" doesn't detect it as an error.
          $ echo abQ | tr Q '\015' >>fast-import.c
          $ git diff --check
      I think this is because the "whitespace" attribute is set to *.[ch] files
      without specifying what kind of errors are caught. It makes git "notice
      all types of errors" (as described in the documentation), but I think it
      is incorrectly setting cr-at-eol, too, and hides this error.
      Signed-off-by: 's avatarNanako Shiraishi <nanako3@lavabit.com>
      Signed-off-by: 's avatarJunio C Hamano <gitster@pobox.com>
  10. 24 Sep, 2008 1 commit
    • Shawn O. Pearce's avatar
      git-gui: Use gitattribute "encoding" for file content display · 1ffca60f
      Shawn O. Pearce authored
      Most folks using git-gui on internationalized files have complained
      that it doesn't recognize UTF-8 correctly.  In the past we have just
      ignored the problem and showed the file contents as binary/US-ASCII,
      which is wrong no matter how you look at it.
      This really should be a per-file attribute, managed by .gitattributes,
      so we now pull the "encoding" attribute data for the given path from
      the .gitattributes (if available) and use that, falling back to UTF-8
      if the attributes are unavailable, git-check-attr is broken, or an
      encoding for this path not specified.
      We apply the encoding anytime we show file content, which currently
      is limited to only the diff viewer and the blame viewer.
      Signed-off-by: 's avatarShawn O. Pearce <spearce@spearce.org>
  11. 11 Feb, 2008 1 commit
    • Junio C Hamano's avatar
      Define the project whitespace policy · 14f9e128
      Junio C Hamano authored
      This establishes what the "bad" whitespaces are for this
      The rules are:
       - Unless otherwise specified, indent with SP that could be
         replaced with HT are not "bad".  But SP before HT in the
         indent is "bad", and trailing whitespaces are "bad".
       - For C source files, initial indent by SP that can be replaced
         with HT is also "bad".
       - Test scripts in t/ and test vectors in its subdirectories can
         contain anything, so we make it unrestricted for now.
      Anything "bad" will be shown in WHITESPACE error indicator in
      diff output, and "apply --whitespace=warn" will warn about it.
      Signed-off-by: 's avatarJunio C Hamano <gitster@pobox.com>