Re: [PATCH] travis-ci: run previously failed tests first, then slowest to fastest

From: Torsten Bögershausen <tboegi@web.de>
Date: Feb 1, 2016, 20:26 UTC
Message-ID: <56AFBF8E.7090809@web.de>
In-Reply-To: <xmqqlh74wb0r.fsf@gitster.mtv.corp.google.com>

On 2016-02-01 19.17, Junio C Hamano wrote:

> Clemens Buchacher <drizzd@aon.at> writes:

[]

Show 5 quoted lines

> 
> IIRC, autocrlf=true would strip CR at the end of line in to-git
> conversion, and would add CR in to-worktree conversion.  So some eol
> conversion may only act in to-git, but some others do affect both,
> and without needing you to touch attributes.

That depends, which version of Git you are running. It has changed from the first version of core.autocrlf:

commit c4805393d73425a5f467f10fa434fb99bfba17ac
Author: Finn Arne Gangstad <finnag@pvv.org>
Date:   Wed May 12 00:37:57 2010 +0200

    autocrlf: Make it work also for un-normalized repositories

    Previously, autocrlf would only work well for normalized
    repositories. Any text files that contained CRLF in the repository
    would cause problems, and would be modified when handled with
    core.autocrlf set.

    Change autocrlf to not do any conversions to files that in the
    repository already contain a CR. git with autocrlf set will never
    create such a file, or change a LF only file to contain CRs, so the
    (new) assumption is that if a file contains a CR, it is intentional,
    and autocrlf should not change that.

    The following sequence should now always be a NOP even with autocrlf
    set (assuming a clean working directory):

    git checkout <something>
    touch *
    git add -A .    (will add nothing)
    git commit      (nothing to commit)

    Previously this would break for any text file containing a CR.

    Some of you may have been folowing Eyvind's excellent thread about
    trying to make end-of-line translation in git a bit smoother.

    I decided to attack the problem from a different angle: Is it possible
    to make autocrlf behave non-destructively for all the previous problem cases?

    Stealing the problem from Eyvind's initial mail (paraphrased and
    summarized a bit):

    1. Setting autocrlf globally is a pain since autocrlf does not work well
       with CRLF in the repo
    2. Setting it in individual repos is hard since you do it "too late"
       (the clone will get it wrong)
    3. If someone checks in a file with CRLF later, you get into problems again
    4. If a repository once has contained CRLF, you can't tell autocrlf
       at which commit everything is sane again
    5. autocrlf does needless work if you know that all your users want
       the same EOL style.

    I belive that this patch makes autocrlf a safe (and good) default
    setting for Windows, and this solves problems 1-4 (it solves 2 by being
    set by default, which is early enough for clone).

    I implemented it by looking for CR charactes in the index, and
    aborting any conversion attempt if this is found.
-----------------------
And my intention is to do a similar fix for the attributes.
More patches coming.