Christian Ebert <blacktrash@gmx.net> [Sun, 21 Dec 2014 13:02:59 +0000] rev 23622
keyword: handle resolve to either parent
Merged files are considered modified at commit time even if only 1 parent
differs. In this case we must use the change context of this parent for
expansion.
The issue went unnoticed for long because it is only apparent until the next
update to the merge revision - except in test-keyword where it was always
staring us in the face.
Christian Ebert <blacktrash@gmx.net> [Sun, 21 Dec 2014 12:53:57 +0000] rev 23621
keyword: update test file syntax
Matt Mackall <mpm@selenic.com> [Mon, 22 Dec 2014 14:49:05 -0600] rev 23620
branches: deprecate -a
Matt Harbison <matt_harbison@yahoo.com> [Sun, 21 Dec 2014 15:06:54 -0500] rev 23619
largefiles: fix a spurious missing file warning with forget (issue4053)
If an uncommitted and deleted file was forgotten, a warning would be emitted,
even though the operation was successful. See the previous patch for
'remove -A' for the exact circumstances, and details about the cause.
Matt Harbison <matt_harbison@yahoo.com> [Sun, 21 Dec 2014 15:04:13 -0500] rev 23618
largefiles: fix a spurious missing file warning with 'remove -A' (issue4053)
The bug report doesn't mention largefiles, but the given recipe doesn't fail
unless the largefiles extension is loaded. The problem only affected normal
files, whether or not any largefiles are committed, and only files that have
not been committed yet. (Files with an 'a' state are dropped from dirstate,
not marked removed.) Further, if the named normal file never existed, the
warning would be printed out twice.
The problem is that the core implementation of remove() calls repo.status(),
which eventually triggers a dirstate.walk(). When the file isn't seen in the
filesystem during the walk, the exception handling finds the file in
dirstate, so it doesn't complain. However, the largefiles implementation
called status() again with all of the original files (including the normal
ones, just dropped). This time, the exception handler doesn't find the file
in dirstate and does complain. This simply excludes the normal files from
the second repo.status() call, which the largefiles extension has no interest
is processing anyway.
Matt Harbison <matt_harbison@yahoo.com> [Sun, 21 Dec 2014 14:42:46 -0500] rev 23617
largefiles: introduce the 'composelargefilematcher()' method
This is a copy/paste (with the necessary tweaks) of the composenormalfilematcher
method currently on default, which does the inverse- this trims the normal files
out of the matcher. It will be used in the next patch.
Durham Goode <durham@fb.com> [Thu, 18 Dec 2014 09:37:14 -0800] rev 23616
context: return dirstate parents in workingctx.ancestors()
workingctx.ancestors() was not returning the dirstate parents as part of the
result set. The only place this function is used is for copy detection when
committing a file, and that code already checks the parents manually, so this
change has no affect at the moment.
I found it while playing around with changing how copy detection works.