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.
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
When dirstate parent is changed with dirstate.setparent before a
revert so it no longer points to where the dirstate refered to, revert
does not remove all files it should:
Revert to a different revision needs also to remove files that are not
found through disptables and not in the context or parent manifest.
This changeset flips the default value of ui.commitsubrepos setting
from True to False and adds a --subrepos flag to commit.
The commit, status, and diff commands behave like this with regard to
recusion and the ui.commitsubrepos setting:
| recurses | recurses
| by default | with --subrepos
--------+---------------+----------------
commit: | commitsubrepo | True
status: | False | True
diff: | False | True
By changing the default from True to False, the table becomes
consistent in the two columns:
* without --subrepos on the command line, commit will abort if a
subrepo is dirty and status/diff wont show changes inside subrepos.
* with --subrepos, all three commands will recurse.
A --subrepos flag on the command line overrides the config settin.g
Matching lines without trailing '\n' was missing the last character.
That seems to have been an unintended side effect of 8abe3f27975c.
The test in c21748e4cd4d documents the bad behaviour.
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.
debugstate would always report files as mode 666 or 777 on Windows.
umask is not used on Windows, but faking and using a defalt value of 022
matches what the test suite uses on Unix.
This has never worked usefully:
- it can't undo a completely unwanted merge, as it leaves the merge in the DAG
- it can't undo a faulty merge as that means doing a merge correctly,
not simply reverting to one or the other parent
Both of these kinds of merge also require coordinated action among
developers to avoid the bad merge continuing to affect future merges,
so we should stop pretending that backout is of any help here.
As backing out a merge now requires a hidden option, it can't be done
by accident, but will continue to 'work' for anyone who's already
dependent on --parent for some unknown reason.
Now 'rollback' after 'import' is less surprising: it rolls back all of
the imported changesets, not just the last one. As an extra added
benefit, you don't need 'rollback -f' after 'import --bypass', which
was an undesired side effect of fixing issue2998 (f9f52d71c33b)..
Note that this is a different take on issue963, which complained that
rollback after importing multiple patches returned the working dir
parent to the starting point, not to the second-last patch applied.
Since we now rollback the entire import, returning the working dir to
the starting point is entirely logical. So this change also undoes
b12d79024900, the fix to issue963, and updates its tests accordingly.
Bottom line: rollback after import was weird before issue963,
understandable since the fix for issue963, and even better now.
This only matters when using the deprecated --base option, and
combining --base with a patch on stdin makes no sense. But it's such
an obvious bug and easy fix that I couldn't pass it by.
The old code printed (with ui.status()) the changeset ID created by
patch N after committing patch N+1, e.g.
applying patch1
applying patch2
applied 1d4bd90af0e4
where 1d4bd90af0e4 is the changeset ID resulting from patch1. That's
just weird. It's also inconsistent: we only reported the changeset ID
when applying >1 patches. And it's inconsistent with 'commit', which
only tells you the new changeset ID in verbose mode. Finally, the
existing code was I18N-hostile, since it concatenated translated
strings.
The new way is to print the just-created changeset ID with ui.note()
immediately after committing it. It also clarifies what the user
message is for easier I18N.
