I'd like to call the function from an extension, passing both "strip"
and "prefix", but it currently only accepts "strip". The only in-tree
caller seems to be mq.py, which doesn't even pass "strip".
Differential Revision: https://phab.mercurial-scm.org/D1413
And introduce a new "apply" operation verb for this case as suggested in
issue5096. This replaces the no longer used "revert" operation.
In interactive revert, when reverting to something else that the parent
revision, display an "apply this change" message with a diff that is not
reversed.
The rationale is that `hg revert -i -r REV` will show hunks of the diff from
the working directory to REV and prompt the user to select them for applying
(to working directory). This contradicts 79cc693b4406 in which it was
decided to have the "direction" of prompted hunks reversed. Later on
[1], there was a broad consensus (but no decision) towards the "as to
be applied direction". Now that --interactive is no longer experimental
(97d754ba45c4), it's time to switch and thus we drop no longer used
"experimental.revertalternateinteractivemode" configuration option.
[1]: https://www.mercurial-scm.org/pipermail/mercurial-devel/2016-November/090142.html
.. feature::
When interactive revert is run against a revision other than the working
directory parent, the diff shown is the diff to *apply* to the working directory,
rather than the diff to *discard* from the working copy. This is in line with
related user experiences with `git` and appears to be less confusing with
`ui.interface=curses`.
We add a 'hunksfilterfn' keyword argument in all functions of the call
stack from changeset_printer.show() to patch.diff(). This is a callable
that will be used to filter out hunks by line range and will be used in
the "-L/--line-range" option of "hg log" command introduced in the
following changesets.
Previously the code caches `i18n._` results in module variables. That causes
issues after an encoding change. Instead of invalidating them manually, we
now just recalculate the translated messages every time `filterpatch` gets
called.
This makes test-commit-interactive.t pass regardless of whether chg or
demandimport is used or not.
.. api: `patch.messages` now lives in `patch.getmessages()`.
Extensions adding new messages should now wrap the `patch.getmessages`
method instead of changing `patch.messages` directly.
Differential Revision: https://phab.mercurial-scm.org/D959
Extensions will want to have interactive thing for more operations or
particulary want to show more verbs. So this patch takes out the message thing
from the function so that extensions can add verbs to this. The curses one is
also not in any function so extensions can add more actions and verbs there.
Differential Revision: https://phab.mercurial-scm.org/D567
Add an option that only ignores whitespaces at EOL. The name of the option is
the same as Git.
.. feature::
Added `--ignore-space-at-eol` diff option to ignore whitespace differences
at line endings.
Differential Revision: https://phab.mercurial-scm.org/D422
This is a regression caused by 10c1efcbeb1e. Code prior to 10c1efcbeb1e
seems to miss the "\ No newline at end of file" line.
Differential Revision: https://phab.mercurial-scm.org/D528
Previously there is a suspicious `if False and delta > 0` which dates back
to the beginning of hgext/record.py (f995f03023c7).
The "trimming context lines" feature could be useful (and is used by the
next patch). So let's enable it. This patch adds a new `maxcontext`
parameter to `recordhunk` and `parsepatch`, changing the `if False`
condition to respect it.
The old `trimcontext` implementation is also wrong - it does not update
`toline` correctly and it does not do the right thing for `before` context.
A doctest was added to guard us from making a similar mistake again.
Since `maxcontext` is set to `None` (unlimited), there is no behavior
change.
The function lost its last caller in ae209b610844 (patch: replace
functions in fsbackend to use vfs, 2014-06-05) when the callers
started relying on the opener to do the join.
patchbackend() seems to call it on an arbitrary backend, so it seems
to be part of the API. Since all subclasses do something in their
close() methods, I decided to let this one raise an exception rather
than just pass.
The old reversehunks code accesses "crecord.uihunk._hunk", which is the raw
recordhunk without crecord selection information, therefore "revert -i"
cannot revert individual lines, aka. issue5337.
The patch rewrites related logic to return the right reverse hunk for
revert. Namely,
1. "fromline" and "toline" are correctly swapped [1]
2. crecord.uihunk generates a correct reverse hunk [2]
Besides, reversehunks(hunks) will no longer modify its input "hunks", which
is more expected.
[1]: To explain why "fromline" and "toline" need to be swapped, take the
following example:
$ cat > a <<EOF
> 1
> 2
> 3
> 4
> EOF
$ cat > b <<EOF
> 2
> 3
> 5
> EOF
$ diff a b
1d0 <---- "1" is "fromline" and "0" is "toline"
< 1 and they are swapped if diff from the reversed direction
4c3 |
< 4 |
--- |
> 5 |
|
$ diff b a |
0a1 <---------+
> 1
3c4 <---- also "4c3" gets swapped to "3c4"
< 5
---
> 4
[2]: This is a bit tricky.
For example, given a file which is empty in working parent but has 3 lines
in working copy, and the user selection:
select hunk to discard
[x] +1
[ ] +2
[x] +3
The user intent is to drop "1" and "3" in working copy but keep "2", so the
reverse patch would be something like:
-1
2 (2 is a "context line")
-3
We cannot just take all selected lines and swap "-" and "+", which will be:
-1
-3
That patch won't apply because of "2". So the correct way is to insert "2"
as a "context line" by inserting it first then deleting it:
-2
+2
Therefore, the correct revert patch is:
-1
-2
+2
-3
It could be reordered to look more like a common diff hunk:
-1
-2
-3
+2
Note: It's possible to return multiple hunks so there won't be lines like
"-2", "+2". But the current implementation is much simpler.
For deletions, like the working parent has "1\n2\n3\n" and it was changed to
empty in working copy:
select hunk to discard
[x] -1
[ ] -2
[x] -3
The user intent is to drop the deletion of 1 and 3 (in other words, keep
those lines), but still delete "2".
The reverse patch is meant to be applied to working copy which is empty.
So the patch would be:
+1
+3
That is to say, there is no need to special handle the unselected "2" like
the above insertion case.
Lines that start in '--' or '++' were previously not counted
as deletions or additions in diffstat, resulting in incorrect
addition/deletion counts. The bug was present if the start
of the line, combined with the diff character resulted
in '---' or '+++'.
diffstatdata will now track, for each file, if it has moved
pas the header section by looking for a line beginning with
'@@'. Once that has happened, lines beginning with '-'
or '+' will be counted for deletions and additions. Once a
line beginning with 'diff' is found, the process starts over.
I'm going to replace hgimporter with a simpler import function, so we can
access to pure/cext modules by name:
# util.py
base85 = policy.importmod('base85') # select pure.base85 or cext.base85
# cffi/base85.py
from ..pure.base85 import * # may re-export pure.base85 functions
This means we'll have to use policy.importmod() function in place of the
standard import statement, but we wouldn't want to write it every place where
C extension modules are used. So this patch makes util host base85 functions.
When diffing binary contents, with certain configs, we can show
"Binary file <name> has changed" without actual content.
That allows a fast path where we could avoid providing actual binary
contents. Note: in that case we still need to test if two contents are the
same, that's done by using "filectx.cmp", which could have its own fast
path.
This seems to be more correct given the table drawn in the previous patch.
Namely, "losedatafn" and "opts.git" are removed, "not opts.text" is added.
- losedatafn: diff output (binary) should not be affected by "losedatafn"
- opts.git: binary testing is helpful for detecting a fast path in the
next path. the fast path can also be used if opts.git is False
- opts.text: if it's set, we should treat the content as non-binary
The end goal is to avoid calling fctx.data() when unnecessary. For example,
if diff.nobinary=1 and files are binary, the expected behavior is to print
"Binary file has changed". That could avoid reading fctx.data() sometimes.
This is mainly to enable an external LFS extension to skip expensive binary
file loading sometimes (read: most of the time with diff.nobinary=1 and
diff.text=0), without any behavior changes to mercurial (i.e. whether a file
is LFS or not does not change any behavior, LFS could be 100% transparent to
users).
Update the hunk selector help message to use the operation name instead
of using "record" for all operations. Extract the help message in the same way
as other single and multiple message line.
Update tests to make sure that both "revert" and "discard" variants are tested.
This patch adds --binary option to `hg diff` and `hg export` to allow more
control about when binary diffs are displayed in Git mode as well as some
tests to verify it behaves correctly (issue5510).
This will be used to make it possible to filter diff hunks based on this range
information.
Now unidiff returns a 'hunks' generator that yield tuple (hunkrange,
hunklines) coming from _unidiff() with 'newline at end of file' processing.
Let unidiff return the list of headers it produces (lines '--- <original>' and
'+++ <new>') apart from diff hunks. In patch.diff(), we combine headers
generated there (not specific to unified format) with those from unidiff().
By returning a list of header lines, we do not append new lines in datetag
inner function of unidiff() so that all header lines are '\n'.join-ed in a
similar way.
Now that the 'vfs' classes moved in their own module, lets use the new module
directly. We update code iteratively to help with possible bisect needs in the
future.
