The final goal here is to be able to parse, return and process arbitrary data
from patch. This mirror the recently added ability to add arbitrary data to
patch headers.
The first step is to return something more flexible, so we return a dict without
changing any other logic.
Python 2.6 introduced the "except type as instance" syntax, replacing
the "except type, instance" syntax that came before. Python 3 dropped
support for the latter syntax. Since we no longer support Python 2.4 or
2.5, we have no need to continue supporting the "except type, instance".
This patch mass rewrites the exception syntax to be Python 2.6+ and
Python 3 compatible.
This patch was produced by running `2to3 -f except -w -n .`.
Python 2.6 introduced a new octal syntax: "0oXXX", replacing "0XXX". The
old syntax is not recognized in Python 3 and will result in a parse
error.
Mass rewrite all instances of the old octal syntax to the new syntax.
This patch was generated by `2to3 -f numliterals -w -n .` and the diff
was selectively recorded to exclude changes to "<N>l" syntax conversion,
which will be handled separately.
Before this patch, exiting a hunk edit in record with a non-zero status lead
to the end of the recording session, losing previously-selected hunks to record.
This patch introduces the more desirable behavior of warning the user and
continuing the recording session.
We had a discussion on the list about the interactive ui for revert. This patch
adds a flag to allow people to test the second alternative (referred to as
proposition 2 on the mailing list). It effectively inverts the signs in the
This patch is part of a series of patches to change the recording ui to reflect
the operation currently running (commit, shelve, revert ...).
This patch adds the default value of the operation argument for record's
standard and curses interface to match what is displayed in the interface
as of today.
This patch is part of a series of patches to change the recording ui to reflect
the operation currently running (commit, shelve, revert ...).
This patch adds a new argument to the recording function to reflect in the UI
what operation we are running.
I tried to fix this issue in the past and had to revert the fix. This is a
second attempt without the regression we found with the first one.
record defines special headers (of file) as headers whose hunk are not shown
to the user for editing, they are used to represent deleted, moved and new
files. Since we want to authorize editing the patch of newly added file we
make the newly added file with some content not special anymore. This entails
that we have to save their content before applying the backup to be able to
revert it if the patch does not apply properly.
We reintroduce the test showing that newly added files can be edited and that
their content is shown to the user.
This passes the existing diff matcher instance down to the copy logic so copy
tracing can be more efficient when possible and only trace copies for matching
files.
This only actually affects forwardcopies (i.e. Given A<-B<-C<-D, it works for
'hg diff -r B -r D foo.txt', but not for 'hg diff -r D -r B foo.txt') since
backward copies require walking all histories, and not just the individual
file's.
This reduces 'hg diff -r A -r B foo.txt' time from 15s to 1s when A and B have
80,000 files different.
Previously we'd request all results, then filter by relative root. This is
clearly inefficient, so we now restrict the matcher to the relative root for
certain easy cases.
The particular case here is when the matcher matches all files. In that case we
can simply create a matcher by the relative root.
This is purely an optimization and has no impact on correctness.
For now this implementation is pretty naive -- it filters out files right
before passing them into trydiff. In upcoming patches we'll add some more
smarts.
This has several advantages compared to resolving it relative to the root:
- '--prefix .' works as expected.
- consistent with upcoming 'hg diff' option to produce relative patches
(I made sure to put in the (glob) annotations this time!)
Although Python supports `X = Y if COND else Z`, this was only
introduced in Python 2.5. Since we have to support Python 2.4, it was
a very common thing to write instead `X = COND and Y or Z`, which is a
bit obscure at a glance. It requires some intricate knowledge of
Python to understand how to parse these one-liners.
We change instead all of these one-liners to 4-liners. This was
executed with the following perlism:
find -name "*.py" -exec perl -pi -e 's,(\s*)([\.\w]+) = \(?(\S+)\s+and\s+(\S*)\)?\s+or\s+(\S*)$,$1if $3:\n$1 $2 = $4\n$1else:\n$1 $2 = $5,' {} \;
I tweaked the following cases from the automatic Perl output:
prev = (parents and parents[0]) or nullid
port = (use_ssl and 443 or 80)
cwd = (pats and repo.getcwd()) or ''
rename = fctx and webutil.renamelink(fctx) or []
ctx = fctx and fctx or ctx
self.base = (mapfile and os.path.dirname(mapfile)) or ''
I also added some newlines wherever they seemd appropriate for readability
There are probably a few ersatz ternary operators still in the code
somewhere, lurking away from the power of a simple regex.
Rev cb4d72125aae adding a parameter here. This breaks third-party extensions
like crecord and also makes the issue fairly hard to fix on the extension's
side if it wants to retain compatibility across Mercurial versions -- in old
versions, the positional argument will be passed into the next unknown
argument, which is 'files'.
The patch also undoes a change to the record extension that is no longer
necessary.
This is preparation for upcoming patches that will add support for applying a
patch within a subdirectory.
We normalize the prefix here because this is the main driver -- all code to
apply patches is expected to go through here.
This is preparation for upcoming patches that will add support for applying a
patch within a subdirectory.
The prefix is applied after path components are stripped.
The code that identifies copies/renames, as well as the filenames
before and after, is now isolated and we can extract it to a function
so it can be overridden by extensions (in particular the narrow clone
extension).
There is not much left of the first block "if opts.git or losedatafn"
block now. The next patch will move the call to getfilectx() out of
that block. We will then be using the defined-ness of 'f1' to tell
whether the file existed in ctx1 (and under what name). We will need
this information whether or not opts.git or losedatafn was set, so
just remove that guard. The only operation in the block that is not
cheap is the call to getfilectx(), but that has an extra 'if opts.git'
guard already.
--ignore-space-change proves that only 'if opts.git or losedatafn:'
was removed.
f1 and f2 are currently set always set to some filename, even for
added or deleted files. Let's instead set them to None to indicate
that one side of the diff doesn't exist. This lets us use the filename
variables instead of the content variables and simplify a bit since
the empty string is not a valid filename. More importantly, it paves
the way for further simplifications.
By having all the checks for lossiness in one place, it becomes much
easier to get an overview of the conditions that lead to losedatafn()
being called. It also makes it obvious that it can not be called
multiple times for a single time (something that was rather tricky to
determine before).
It's not obvious, but every path in the 'if opts.git or losedatafn:'
block will have checked whether the file is binary [1]. Let's assign
the result of this check to a variable so we can simplify by checking
'binary and opts.git' in only one place instead of every place we
currently assign to 'binarydiff'.
[1] Except when deleting an empty file, but checking whether an empty
string is binary is very cheap anyway.
It seems natural that each element in the list corresponds to one line
of output. That is currently true, but only because each element in
the list has a trailing newline. Let's drop those newlines and instead
add them when we print the headers.
By moving the condition out of diffline(), the call site becomes
clearer and diffline() no longer closes on any variables.
Note that this changes the value of the header variable from [''] to
[], but there is no difference in how these two are treated by the
following code. The new value seems more natural anyway.
Now that there is only a single call to addmodehdr() left, and there
is other similar code (for new/deleted files) around that call site,
let's inline the function there. That also makes it clearer under what
circumstances the header is actually written (when modes differ).
This is the first step towards simplifying the big loop in
trydiff(). This will make both the header code and the non-header code
clearer, and it prepares for further simplification of the many nested
if-statements in the body of the loop.
Use '1' and '2' as suffix for names just like in the parameters
'ctx[12]':
to,tn -> content1,content2
a,b -> f1, f2
omode,mode -> mode1,mode2
omode,nmode -> mode1,mode2
onode,nnode -> node1,node2
oflag,nflag -> flag1,flag2
oindex,nindex -> index1,index2
When creating a diff with copy/rename enabled, we consider added files
and check if they are either copy sources or targets. However, an
added file should never be a copy source. The test suite seems to
agree with this: all tests pass if we raise an exception when an added
file is a copy source. So, let's simplify the code by dropping the
conditions that are never true.
For those interested in the historical reasons:
Before commit c15c00e7afba (patch: separate reverse copy data
(issue1959), 2010-02-11), 'copy' seems to have been a bidirectional
map. Then that commit split it up into two unidirectional maps and
duplicated the logic to look in both maps. It was still needed at that
point to look in both maps, as the copy detection was poor and could
sometimes be reported in reverse.
A little later came 5a644704d5eb (copies: rewrite copy detection for
non-merge users, 2012-01-04). That commit fixed the copy detection to
be backwards when it should, and made the hacks in trydiff
unnecessary.
We started updating 'modifiedset' in e85e48ffb83e (trydiff: simplify
checking for additions, 2014-12-23) but in the same commit, we removed
the last use of the variable. Clean it up.
When a binary source has been copied or renamed into a non-binary
file, we don't check whether the copy source was binary. There is a
code comment explaining that a git mode will be forced anyway in order
to capture the copy record (i.e. losedatafn() will be called). This is
true, but forcing git mode is not the only effect binary files have:
when git mode was already requested, we use the binary-ness to tell us
whether to use a regular unified diff or a git binary diff. The user
sees this as a "Binary file $file has changed" instead of the binary
The 'dodiff' variable is initialized to True and may later be set to
either False or "binary". When it's set to False, we skip everything
after that point, so we can simplify by instead continue-ing (the
loop). We can then also drop the 'if dodiff', since it will always be
true.
The conditional-ness is not clear from the name and there is only one
caller, so it's clearer to check on the call site. Moving it also
makes addindexmeta() no longer close on the 'opts' variable.
In the body of the loop in trydiff(), there are conditions like:
addedset or (f in modifiedset and to is None)
The second half of that expression is to account for the fact that
merge-in additions appear as additions. By instead fixing up the sets
of modified and added files to compensate for this fact, we can
simplify the body of the loop. It also fixes one case where the
addedset was checked without the additional check (the "have we
already reported a copy above?" case in the code, also see fixed test
case).
The similar condition with 'removedset' in it seems to have served no
purpose even before this change, so it could have been simplified even
before.
Note that there is a comment saying "ctx2 date may be dynamic". The
comment was introduced in 8ed3d2a60500 (patch: use contexts for diff,
2006-12-25), but it seems like it stopped being dynamic in that very
changeset -- before that changeset, the date seems to have been the
file's mtime, but after the changeset, it seems to be the changeset's
timestamp (current time for workingctx). Since no one seems to have
missed the "dynamicness", let's simplify and extract a date2 for
symmetry with date1.
This only has a noticeable effect on diffs touching A LOT of
files. For example, it takes
hg diff -r FIREFOX_AURORA_30_BASE -r FIREFOX_AURORA_35_BASE
from 1m55.465s to 1m32.354s. That diff has over 50k files.
These aren't exactly format-breaking features -- just ones for which patches
applied to a repo will produce incorrect commits, In any case, some commands
like record and annotate only care about this feature.
Not all callers are interested in all diffopts -- for example, commands like
record (which use diff internally) break when diffopts like noprefix are
enabled. This function will allow us to add flags that callers can use to
enable only the features they're interested in.
In an upcoming patch we'll enable support as an option to 'hg diff' as well.
The tests reflect the current state of the world -- as we add support we'll see
changes in the test output.
Upcoming patches will add an option that will almost certainly break diff
output parsers when enabled. Add support for forcing an option to something in
plain mode, as a fallback. Options passed in via the CLI are not affected,
though -- it is assumed that any script passing the option in explicitly knows
what it is doing.
The following patch splits up changed lines along tabs (using
re.findall), and gives them a "diff.tab" label. This can be used by
the color extension for colorising tabs, like it does right now with
trailing whitespace.
I also provide corresponding tests.
The internal API used IOError to indicate that a file should be marked as
removed.
There is some correlation between IOError (especially with ENOENT) and files
that should be removed, but using IOErrors to represent file removal internally
required some hacks.
Instead, use the value None to indicate that the file not is present.
Before, spurious IO errors could cause commits that silently removed files.
They will now be reported like all other IO errors so the root cause can be
fixed.
