Matt Mackall <mpm@selenic.com> [Tue, 11 Nov 2014 18:43:19 -0600] rev 23266
merge with stable
Matt Mackall <mpm@selenic.com> [Tue, 11 Nov 2014 17:25:09 -0600] rev 23265
Added signature for changeset 643c58303fb0
Matt Mackall <mpm@selenic.com> [Tue, 11 Nov 2014 17:24:47 -0600] rev 23264
Added tag 3.2.1 for changeset 643c58303fb0
Augie Fackler <raf@durin42.com> [Mon, 10 Nov 2014 13:20:56 -0500] rev 23263
run-tests: use a try/except ladder instead of looking for a specific version
This ensures we get json instead of simplejson in as many places as possible.
Augie Fackler <raf@durin42.com> [Mon, 10 Nov 2014 13:27:25 -0500] rev 23262
hghave: use a less brittle have-json check
Sean Farley <sean.michael.farley@gmail.com> [Wed, 15 Oct 2014 12:39:19 -0700] rev 23261
sortdict: add insert method
Future patches will allow extensions to choose which order a namespace should
output in the log, so we add a way for sortdict to insert to a specific
location.
Sean Farley <sean.michael.farley@gmail.com> [Sun, 09 Nov 2014 13:15:28 -0800] rev 23260
sortdict: add iteritems method
Future patches will start using sortdict for log operations where order is
important. Adding iteritems removes the headache of having to remember to use
items() if the object is a sortdict.
Martin von Zweigbergk <martinvonz@google.com> [Sat, 08 Nov 2014 23:13:39 -0800] rev 23259
addremove: add back forgotten files (BC)
After running "hg forget README && hg addremove", README will still be
reported as removed, while "hg forget README && hg add README" adds it
back so it gets reported as clean. It seems like they should behave
the same. Furthermore, it seems like no files should remain untracked
after 'hg addremove && hg commit' (or 'hg commit -A'). For these
reasons, change the behavior of addremove so it does add forgotten
files back.
The problem is with scmutil._interestingfiles(), which reports the
file as removed, so scmutil.addremove() does not add it. Fix by
teaching _interestingfiles() to report forgotten files separately from
removed files and make addremove() add forgotten files back. However,
do not treat forgotten files as sources for rename detection. Note
that since removed and forgotten files are treated the same before
this change, forgotten files were considered sources for rename
detection.
Also update the other caller, marktouched(), in the same way as
addremove().
Martin von Zweigbergk <martinvonz@google.com> [Mon, 10 Nov 2014 14:51:18 -0800] rev 23258
add: add back forgotten files even when not matching exactly (BC)
I accidentally did 'hg forget .' and tried to undo the operation with
'hg add .'. I expected the files to be reported as either modified or
clean, but they were still reported as removed. It turns out that
forgotten files are only added back if they are listed explicitly, as
shown by the following two invocations. This makes it hard to recover
from the mistake of forgetting a lot of files.
$ hg forget README && hg add README && hg status -A README
C README
$ hg forget README && hg add . && hg status -A README
R README
The problem lies in cmdutil.add(). That method checks that the file
isn't already tracked before adding it, but it does so by checking the
dirstate, which does have an entry for forgotten files (state 'r'). We
should instead be checking whether the file exists in the
workingctx. The workingctx is also what we later call add() on, and
that method takes care of transforming the add() into a normallookup()
on the dirstate.
Since we're changing repo.dirstate into wctx, let's also change
repo.walk into wctx.walk for consistency (repo.walk calls wctx.walk,
so we're simply inlining the call).
Martin von Zweigbergk <martinvonz@google.com> [Tue, 11 Nov 2014 10:16:54 -0800] rev 23257
context.status: explain "caching reasons" more fully
Where we "load earliest manifest first for caching reasons", elaborate
on what "caching reasons" refers to. Text provided by Matt in
http://thread.gmane.org/gmane.comp.version-control.mercurial.devel/73235/focus=73578.