`opts['unified'] = '0'` tries to reduce the number of lines to be
processed by patch.diffstat, but here it does not affect diffopts,
thus it does not make sense.
Instead, we can change `diffopts.context` directly.
Added test case for qdiff --stat.
This fixes an incompatibility with patch(1), which also uses --reverse
for reversed diffs. The --inverse flag was added in 0f0383897d54. That
name was chosen over --reverse since it was thought that --reverse
would make --rev ambiguous.
It turns out that both flags can co-exist, with the cost that --rev
can no longer be shortened to --r and --re. Since one can always use
the short -r option, this is not a real problem.
Previous code was computing hunks then checking if these hunks could be ignored
when taking whitespace/blank-lines options in accounts. This approach is simple
but fails with hunks containing both whitespace and non-whitespace changes, the
whole hunk is emitted while it can be mostly made of whitespace. The new
version normalize the whitespaces before hunk generation, and test for
blank-lines afterwards.
Most of the time, one can reverse a diff by swapping the revisions passed with
-r but it happens that if you use the global -R, and diff against the tip of
the current repo, you can't swap the revisions. One use-case for that is
reviewing changes from a bundle before unbundling. One could also pipe the
output of `hg diff` to a command line filter that reverses the diff, but that
would remove the benefit from color diffs. Therefore, having an option in
`hg diff` to reverse a diff is a good thing.
The option flag selection was tricky. GNU patch uses -R/--reverse but -R is
already used as a global option and --reverse would make --rev ambiguous.
When navigating through a patch series by qpushing and qpopping it was easy to
get lost because qpop was silent. I found myself often running qnext after qpop
to see which patch I just dropped - especially if I was about to qrm it. This
patch makes qpop more symmetric to qpush by showing which patches are
applied/"unapplied".
I think it is a good change even though it changes output by adding a new line
of output.
This extension produces quite a lot of informational messages during
its normal operation and it is hard to say which strings can be
changed and which cannot.
We'd mistakenly made the -p option always on, which meant there was no
way to turn it off. It also meant that we were sometimes splitting
multibyte characters in function name, which isn't a good default.
