With this change, "hg clone" looks like this:
% hg clone http://example.com/repo/big big
requesting all changes
adding changesets
adding manifests
adding file changes
added XXX changesets with XXX changes to XXX files
updating working directory
XXX files updated, XXX files merged, XXX files removed, XXX files unresolved
So the user sees
% hg clone http://example.com/repo/big big
requesting all changes
adding changesets
adding manifests
adding file changes
added XXX changesets with XXX changes to XXX files
updating working directory
while Mercurial is writing to disk to populate the working directory
With this change, "hg clone" looks like this:
% hg clone big big-work
updating working directory
XXX files updated, XXX files merged, XXX files removed, XXX files unresolved
This can make a difference when there are filters involved and
decode(encode(working-dir-data)) != working-dir-data
even though
encode(decode(repo-data)) == repo-data
An example is a working dir file that uses only \n when you're using
the win32text extension.
While some can function with just some text and an optional command name,
others may want a repository object, a ui object, and a file path.
Use the enhanced information to good effect in win32text.dumbdecode's warning.
While the win32text extension does LF <-> CRLF conversion, and will issue a
warning in case a file already in the repository uses CRLF, it provides no
mechanism for verifying that incoming changes use LF. In a large development
team with some Windows users, it is virtually guaranteed that someone will
forget to set up the encode filter correctly and accidentally check in a file
using CRLF, which can cause warnings for other Windows users when they next
fetch changes. Since this is a general problem it is desirable to have a
pre-commit (or -push) hook available to reject such accidents earlier rather
than trying to fix them up after the fact.
