Skip to content

HTTPS clone URL

Subversion checkout URL

You can clone with
or
.
Download ZIP
Commits on Feb 6, 2008
  1. @sprohaska @gitster

    safecrlf: Add mechanism to warn about irreversible crlf conversions

    sprohaska authored gitster committed
    CRLF conversion bears a slight chance of corrupting data.
    autocrlf=true will convert CRLF to LF during commit and LF to
    CRLF during checkout.  A file that contains a mixture of LF and
    CRLF before the commit cannot be recreated by git.  For text
    files this is the right thing to do: it corrects line endings
    such that we have only LF line endings in the repository.
    But for binary files that are accidentally classified as text the
    conversion can corrupt data.
    
    If you recognize such corruption early you can easily fix it by
    setting the conversion type explicitly in .gitattributes.  Right
    after committing you still have the original file in your work
    tree and this file is not yet corrupted.  You can explicitly tell
    git that this file is binary and git will handle the file
    appropriately.
    
    Unfortunately, the desired effect of cleaning up text files with
    mixed line endings and the undesired effect of corrupting binary
    files cannot be distinguished.  In both cases CRLFs are removed
    in an irreversible way.  For text files this is the right thing
    to do because CRLFs are line endings, while for binary files
    converting CRLFs corrupts data.
    
    This patch adds a mechanism that can either warn the user about
    an irreversible conversion or can even refuse to convert.  The
    mechanism is controlled by the variable core.safecrlf, with the
    following values:
    
     - false: disable safecrlf mechanism
     - warn: warn about irreversible conversions
     - true: refuse irreversible conversions
    
    The default is to warn.  Users are only affected by this default
    if core.autocrlf is set.  But the current default of git is to
    leave core.autocrlf unset, so users will not see warnings unless
    they deliberately chose to activate the autocrlf mechanism.
    
    The safecrlf mechanism's details depend on the git command.  The
    general principles when safecrlf is active (not false) are:
    
     - we warn/error out if files in the work tree can modified in an
       irreversible way without giving the user a chance to backup the
       original file.
    
     - for read-only operations that do not modify files in the work tree
       we do not not print annoying warnings.
    
    There are exceptions.  Even though...
    
     - "git add" itself does not touch the files in the work tree, the
       next checkout would, so the safety triggers;
    
     - "git apply" to update a text file with a patch does touch the files
       in the work tree, but the operation is about text files and CRLF
       conversion is about fixing the line ending inconsistencies, so the
       safety does not trigger;
    
     - "git diff" itself does not touch the files in the work tree, it is
       often run to inspect the changes you intend to next "git add".  To
       catch potential problems early, safety triggers.
    
    The concept of a safety check was originally proposed in a similar
    way by Linus Torvalds.  Thanks to Dimitry Potapov for insisting
    on getting the naked LF/autocrlf=true case right.
    
    Signed-off-by: Steffen Prohaska <prohaska@zib.de>
Something went wrong with that request. Please try again.