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
The self patching of files when diffed with a backup is a bit peculiar to me.
It makes sense in mpatch, that's less clear in mercurial patching code. Let's
document and preserve it for now.
Like some renames or copy operations, binary file removal does not generate any
"file" or "hunk" action, but was not tagged as such and let iterhunk() assume
no hunk was applied for the deleted file.
The prose section of the help text for the command already said that -u and -m
are accepted, but -u was not listed in the table of options, and did not work.
Useful when accepting patches from other people made by hg diff rather than hg
export. For completeness, also accepting -d DATE.
[CHANGES: rebased against 2f0da487820f, --no-commit option.]
- use "branch 'foo'" to distinguish from "branch merge".
- commit messags can be empty (to abort commits)
- Added value for editor message: Tell about HG: lines like CVS does.
The main problem was that dirstate.getcwd() returned just "",
which was interpreted as "we're at the repo root". It now returns
an absolute path.
The util.pathto function was also changed to deal with the "cwd is
an absolute path" case.