[PREVIEW] line-endings support

[John Arbash Meinel]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Talden wrote:
|>  Doing it based on rules means that they're dependent on filename, which
|>  means that renames can change a file's EOL behavior.  I don't see that
|>  as a good thing.  Maybe it would be okay if there was a warning about
|>  the change in behavior when commit or status was invoked.
|
| An excellent point. Certainly the suggested mechanism depends upon
| users specifying patterns that encompass all names in use for the
| life-time of the content.
|
| Luckily most patterns will be extension focused and most renames won't
| change extensions.
|
| For the exceptions it may be important to have a warning and possibly
| even fork off absolute-path entries in the EOL rules to follow files
| that step outside their patterns.
| This would affect move/rename and remove behaviours at the least.
| These absolute-path rules _should_ be exceptions.
|
| There's a strong need for this facility to be versioned and I'm sure
| there'll be some pain idetifying all of the interesting cases in that
| feature. (merge conflicts, commit ordering, etc).
|
| Here's a quick run over the idea of mixing absolute paths and patterns
| and the maintenance of them -- apologies now for a hasty brain-dump...
|
|   * The patterns file is stored in a canonical order and formatting (and the UI
|     provide a means to canonicalise it and the commit mechanism does
| so before commits) -
|     This should reduce conflict cases using the usual line-based
| merging and may aid
|     searches for absolute path matching.

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.)

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.)

If we make the patterns *only* filename extensions *or* absolute paths, we can
make some of the processing operations a lot faster. And you are a lot less
likely to run into problems. But then what do you do about extension-less files
(Makefile, configure, bzr, etc).

|   * Provide a custom merger - if the file is in a canonical order then the
|     conventional line-based merging approach can be used with a fall-back to
|     auto-resolve certain conflicts such as "same-line, different pattern".
|   * Have the UI provide a way of reapplying the EOL rules to the
| working tree and that
|     true conflicts in the EOL config result in LF behaviour (the
| format in the repo itself)
|     until EOL conflicts are resolved.
|   * Changing EOL rules should apply those changes to the working-tree.

John
=:->
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (Cygwin)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iEYEARECAAYFAkgHgjIACgkQJdeBCYSNAAORwgCfcK88acm2/8IWNcp5KKhfRPFQ
XF8AoIq28bnHolLDgKXA+duIOGDkZL6n
=g2kw
-----END PGP SIGNATURE-----