Re-add MHTML files so that they're represented with LF line endings. They'll still be CRLF on check…

Re-add MHTML files so that they're represented with LF line endings. They'll still be CRLF on checkout.

In crrev.com/bb2148f3eed355794122db8d31d5eed903c53ced, a .gitattributes
file with this line was added to the mhtml directory:

    *.mht text eol=crlf

Git internally represents text files with LF line endings, but before
that file was created, the files were checked in with CRLFs. This is an
invalid state, but it doesn't show in a fresh clone or after `git reset
--hard` (probably some optimization in Git which assumes that
no files in a fresh repo can have changes).

You can trigger the issue by touching any .mht file in this directory.
For example:

    touch third_party/WebKit/LayoutTests/mhtml/transfer_encoding_7bit.mht

Now, a `git status` will show that file as modified, and no combination
of `git checkout <file>` and `git reset <file>` will make it stop
showing up as modified. A `git reset --hard` on the whole repo will
restore Git's ignorance. You can also reveal the issue by
deleting/moving .git/index and then running `git reset` to recreate it:
all of these files will now show up as modified.

As far as I can tell, the right solution is to check all of these files
in again. This shouldn't have any observable effects other than the
issue described above no longer being reproducible.

Another option is to edit the .gitattributes file to treat these files
as binary.

BUG=656177
R=mark@chromium.org

Committed: https://crrev.com/89a9d64a0cdaba5a5f5be5a098b99769074bf623
Patch from Sidney San Martín <sdy@chromium.org>;.

Cr-Commit-Position: refs/heads/master@{#425694}

[Sidney San Martín, 2016-10-14 22:58:09]

The CQ bit was checked by sdy@chromium.org to run a CQ dry run

[commit-bot: I haz the power, 2016-10-14 22:58:34]

Dry run: CQ is trying da patch. Follow status at
 
https://chromium-cq-status.appspot.com/v2/patch-status/codereview.chromium.or...

[commit-bot: I haz the power, 2016-10-14 23:01:46]

The CQ bit was unchecked by commit-bot@chromium.org

[commit-bot: I haz the power, 2016-10-14 23:01:46]

Dry run: Try jobs failed on following builders:
  android_clang_dbg_recipe on master.tryserver.chromium.android (JOB_FAILED,
https://build.chromium.org/p/tryserver.chromium.android/builders/android_clan...)
  android_compile_dbg on master.tryserver.chromium.android (JOB_FAILED,
https://build.chromium.org/p/tryserver.chromium.android/builders/android_comp...)
  cast_shell_linux on master.tryserver.chromium.linux (JOB_FAILED,
http://build.chromium.org/p/tryserver.chromium.linux/builders/cast_shell_linu...)
  chromeos_x86-generic_chromium_compile_only_ng on
master.tryserver.chromium.linux (JOB_FAILED,
http://build.chromium.org/p/tryserver.chromium.linux/builders/chromeos_x86-ge...)
  linux_chromium_chromeos_compile_dbg_ng on master.tryserver.chromium.linux
(JOB_FAILED,
http://build.chromium.org/p/tryserver.chromium.linux/builders/linux_chromium_...)
  linux_chromium_compile_dbg_ng on master.tryserver.chromium.linux (JOB_FAILED,
http://build.chromium.org/p/tryserver.chromium.linux/builders/linux_chromium_...)
  linux_chromium_rel_ng on master.tryserver.chromium.linux (JOB_FAILED,
http://build.chromium.org/p/tryserver.chromium.linux/builders/linux_chromium_...)
  mac_chromium_compile_dbg_ng on master.tryserver.chromium.mac (JOB_FAILED,
http://build.chromium.org/p/tryserver.chromium.mac/builders/mac_chromium_comp...)
  mac_chromium_rel_ng on master.tryserver.chromium.mac (JOB_FAILED,
http://build.chromium.org/p/tryserver.chromium.mac/builders/mac_chromium_rel_...)

[Sidney San Martín, 2016-10-14 23:07:25]

sdy@chromium.org changed reviewers:
+ mark@chromium.org

[Sidney San Martín, 2016-10-14 23:07:26]

Looks like this can't be landed through the CQ. I'll bug you to talk about it on
Monday :).

[Mark Mentovai, 2016-10-17 13:33:04]

LGTM

[commit-bot: I haz the power, 2016-10-17 16:28:28]

Description was changed from

==========
Re-add MHTML files so that they're represented with LF line endings. They'll
still be CRLF on checkout.

In crrev.com/bb2148f3eed355794122db8d31d5eed903c53ced, a .gitattributes
file with this line was added to the mhtml directory:

    *.mht text eol=crlf

Git internally represents text files with LF line endings, but before
that file was created, the files were checked in with CRLFs. This is an
invalid state, but it doesn't show in a fresh clone or after `git reset
--hard` (probably some optimization in Git which assumes that
no files in a fresh repo can have changes).

You can trigger the issue by touching any .mht file in this directory.
For example:

    touch third_party/WebKit/LayoutTests/mhtml/transfer_encoding_7bit.mht

Now, a `git status` will show that file as modified, and no combination
of `git checkout <file>` and `git reset <file>` will make it stop
showing up as modified. A `git reset --hard` on the whole repo will
restore Git's ignorance. You can also reveal the issue by
deleting/moving .git/index and then running `git reset` to recreate it:
all of these files will now show up as modified.

As far as I can tell, the right solution is to check all of these files
in again. This shouldn't have any observable effects other than the
issue described above no longer being reproducible.

Another option is to edit the .gitattributes file to treat these files
as binary.

BUG=656177
==========

to

==========
Re-add MHTML files so that they're represented with LF line endings. They'll
still be CRLF on checkout.

In crrev.com/bb2148f3eed355794122db8d31d5eed903c53ced, a .gitattributes
file with this line was added to the mhtml directory:

    *.mht text eol=crlf

Git internally represents text files with LF line endings, but before
that file was created, the files were checked in with CRLFs. This is an
invalid state, but it doesn't show in a fresh clone or after `git reset
--hard` (probably some optimization in Git which assumes that
no files in a fresh repo can have changes).

You can trigger the issue by touching any .mht file in this directory.
For example:

    touch third_party/WebKit/LayoutTests/mhtml/transfer_encoding_7bit.mht

Now, a `git status` will show that file as modified, and no combination
of `git checkout <file>` and `git reset <file>` will make it stop
showing up as modified. A `git reset --hard` on the whole repo will
restore Git's ignorance. You can also reveal the issue by
deleting/moving .git/index and then running `git reset` to recreate it:
all of these files will now show up as modified.

As far as I can tell, the right solution is to check all of these files
in again. This shouldn't have any observable effects other than the
issue described above no longer being reproducible.

Another option is to edit the .gitattributes file to treat these files
as binary.

BUG=656177
R=mark@chromium.org

Committed: https://crrev.com/89a9d64a0cdaba5a5f5be5a098b99769074bf623
Patch from Sidney San Martín <sdy@chromium.org>.

Cr-Commit-Position: refs/heads/master@{#425694}
==========

[commit-bot: I haz the power, 2016-10-17 16:28:30]

Patchset 1 (id:??) landed as
https://crrev.com/89a9d64a0cdaba5a5f5be5a098b99769074bf623
Cr-Commit-Position: refs/heads/master@{#425694}