splitblock() was added to handle blocks returned by bdiff.blocks() which differ
only by blank lines but are not made only of blank lines. I do not know exactly
how it could happen but mdiff.blocks() threshold behaviour makes me think it
can if those blocks are made of very popular lines mixed with popular blank
lines. If it is proven to be wrong, the function can be dropped.
The first implementation made annotate share diff configuration entries. But it
looks like users will user -w/b for annotate but not for diff, on both the
command line and hgweb. Since the latter cannot use command line entries, we
introduce a new [annotate] section duplicating the diff whitespace options.
With "wp1" and "wp2" the current working directory parents, "p1" and "p2" the
patch parents and "parents" the resulting commit parents, the current behaviour
is:
--bypass --exact p2 parents
0 0 0 [wp1, wp2]
0 0 1 [wp1, wp2]/buggy
0 1 0 [p1]
0 1 1 [p1, p2]
1 0 0 [wp1, wp2]
1 0 1 [p1, p2]
1 1 0 [p1]
1 1 1 [p1, p2]
The original behaviour before 1f543fd375c5 was:
--bypass --exact p2 parents
0 0 0 [wp1, wp2]
0 0 1 if p1 == wp1 then [p1, p2] otherwise [wp1, wp2]
0 1 0 [p1]
0 1 1 [p1, p2]
This patch restores the previous behaviour when --bypass is not set, and align
--bypass behaviour when --exact is not set with merge diffs.
7ad43b163555 introduced a new block in test-convert-bzr-directories.t
which produces a slightly different output with older bzr versions.
Tested with bzr 1.5 on Debian lenny.
In particular, we do not allow:
- grafting an already grafted cset onto its original branch
- grafting already grafted csets with the same origin onto each other
"hg status" may treat cache missed largefiles as "removed" incorrectly.
assumptions for problem case:
- there is no cache for largefile "L"
- at first, update working directory to the revision in which "L" is
not yet added,
- then, update working directory to the revision in which "L" is
already added
and now, "hg status" treats "L" as "removed".
current implementation does not allocate entry for cache missed
largefile in ".hg/largefiles/dirstate", but files without
".hg/largefiles/dirstate" entry are treated as "removed" by largefiles
extension.
"hg revert" can not recover from this situation, but "rm -rf
.hg/largefiles", because it causes dirstate rebuilding.
this patch invokes normallookup() for cache missed largefiles to
allocate entry in ".hg/largefiles/dirstate", so "hg status" can treat
it as "missing" correctly.
Change the behavior of the forget command such that explicit paths in
subrepos are handled by forgetting the file in the subrepo. This eliminates the
previous behavior where if you called "hg forget" for an explicit path in a
subrepo, it would state that the file is already untracked.
When storing/restoring a nullmerge (-2), a 'standard' conversion was made
and an existing changeset was wrongly used.
Nullmerge should instead be treated as a special case.
Prior to this patch "hg diff -U0", i.e., zero lines of context, would
output hunk headers with a start line one greater than what GNU patch
and git output. Guido van Rossum documents the unified diff format[1]
as having a start line value "one lower than one would expect" for
zero length hunks.
Comparing the behaviour of the three systems prior to this patch in
transforming
c1
c3
to
c1
c2
c3
- GNU "diff -U0" reports the hunk as "@@ -1,0 +2 @@"
- "git diff -U0" reports the hunk as "@@ -1,0 +2 @@"
- "hg diff -U0" reports the hunk as "@@ -2,0 +2,1 @@"
After this patch, "hg diff -U0" reports "@@ -1,0 +2,1 @@".
Since "hg export --config diff.unified=0" outputs zero-context unified
diffs, "hg import" has also been updated to account for start lines
one less than expected for zero length hunk ranges.
[1]: http://www.artima.com/weblogs/viewpost.jsp?thread=164293
With renames like:
a -> b
a/c -> a/c
We were ignoring or duplicating the second one instead of leaving files
unchanged or moving them to their proper destination only.
To avoid this, we process the files in reverse lexicographic order, from most
to least specific change, and ignore files already processed.
v2:
- Add a test
- Change "reverse=1" into "reverse=True"
This fix mirrors the changes made to test-doctest.py in 04cfbbc5ae97
and 39599b7929c4.
Without this change, tests running heredoctest.py can fail on certain
versions of OS X when TERM is set to xterm-256color:
$ /opt/local/Library/Frameworks/Python.framework/Versions/2.7/Resources/Python.app/Contents/MacOS/Python -m heredoctest <<EOF
> >>> open('b', 'w').write('this' * 1000)
> EOF
+ \x1b[?1034h (no-eol) (esc)
A similar problem occurs with test-url.py:
$ ./run-tests.py test-url.py
--- .../tests/test-url.py.out
+++ .../tests/test-url.py.err
@@ -0,0 +1 @@
+
ERROR: .../test-url.py output changed
!
Failed test-url.py: output changed
# Ran 1 tests, 0 skipped, 1 failed.
# this change redones part of e0051068893a, backed out by 38c00c035629
Some character encodings use ASCII characters other than
control/alphabet/digit as a part of multi-bytes characters, so direct
replacing with such characters on strings in local encoding causes
invalid byte sequences.
[mpm: test changed to simple doctest]
