[PREVIEW] line-endings support

[Stefan Monnier]

>> The big problem I have with this is how to handle when a file matches
>> multiple patterns. One clear example is absolute paths versus
>> extensions (though generally you would say that the abspath would
>> take precedence.)

For `bzrignore' rules, we if multiple patterns match a file, it makes no
difference.  The only "conflicting patterns" is when a file matches
a bzrignore pattern but is added, in which case the "added" takes precedence.

If EOL properties are only specified through patterns, we need to let
the user specify such conflicting rules.

>> I can certainly create multiple rules that would match a single
>> path. In that case, do they stack? Does one "win"? What are the rules
>> for that (comes first alphabetically, comes first on the search list,
>> comes last on the search list, matches more of the filename, etc.)

> In the case of gitattributes, the doc is pretty clear:

> * lower patterns in the file take precedence
> * .gitattributes files have lower priority the further up the tree
>   they are.

> Those rules look good to me.

They make sense.  I'm not sure how they deal with situations such as

   *.txt is LF
   windows.txt is CRLF

all in the same directory.  I think it makes sense to provide
a precedence rule that says "first rule to match is the one obeyed".
If there are several files, then order the files by "proximity".

This "first match has precedence" ordering has a long history of
successful use (in lex, in programming languages with pattern matching
such as Prolog, SML, Haskell, ...).  It is simple to understand and
intuitive, and it allows the user to provide as many refinements as he
wants (last, the general case, just before that, the exceptions, before
that the exceptions to the exceptions, ...).


        Stefan