Thu, 06 Jul 2017 16:37:36 -0700 sparse: override __repr__ in matchers
Martin von Zweigbergk <martinvonz@google.com> [Thu, 06 Jul 2017 16:37:36 -0700] rev 33315
sparse: override __repr__ in matchers sparse.py in FB's hg-experimental repo switched to using __repr__ for non-sparse matchers soon after hg core started overriding __repr__ in the matchers in match.py (because the core matchers also stopped having "includepat" and other attributes that sparse used to depend on). Let's finish that migration by implementing __repr__ in the sparse matchers as well. That also lets us remove the special handling of them in _hashmatcher().
Thu, 06 Jul 2017 14:17:02 -0700 tests: fix reference to undefined variable
Martin von Zweigbergk <martinvonz@google.com> [Thu, 06 Jul 2017 14:17:02 -0700] rev 33314
tests: fix reference to undefined variable The delaypush() function had a reference to "repo" that was clearly supposed to be "pushop.repo". Instead of just fixing that, let's extract "pushop.repo.ui" to a variable, since that's the only piece of the repo that's needed in the function. I have not looked into why I saw a different result in the test to start with, but that's for another patch anyway.
Tue, 01 Dec 2015 09:19:54 -0800 shelve: don't reimplement mergestate.unresolved()
Martin von Zweigbergk <martinvonz@google.com> [Tue, 01 Dec 2015 09:19:54 -0800] rev 33313
shelve: don't reimplement mergestate.unresolved()
Mon, 23 Nov 2015 09:37:12 -0800 summary: don't reimplment mergestate.unresolved()
Martin von Zweigbergk <martinvonz@google.com> [Mon, 23 Nov 2015 09:37:12 -0800] rev 33312
summary: don't reimplment mergestate.unresolved()
Tue, 01 Dec 2015 09:26:33 -0800 mergestate: implement unresolvedcount() in terms of unresolved()
Martin von Zweigbergk <martinvonz@google.com> [Tue, 01 Dec 2015 09:26:33 -0800] rev 33311
mergestate: implement unresolvedcount() in terms of unresolved() This simplifies the method slightly. It does create a full list of paths while doing so, but it's not a lot of data anyway (besides, I would think references to strings are no larger than (references to?) True).
Tue, 01 Dec 2015 09:26:10 -0800 mergestate: make unresolved() use iteritems()
Martin von Zweigbergk <martinvonz@google.com> [Tue, 01 Dec 2015 09:26:10 -0800] rev 33310
mergestate: make unresolved() use iteritems() mergestate.unresolved() is a generator, so it seems better for it to rely on iteritems() than items(), although it also seems unlikely for it to make a noticeable difference.
Fri, 30 Jun 2017 23:58:59 -0700 changegroup: don't fail on empty changegroup (API)
Martin von Zweigbergk <martinvonz@google.com> [Fri, 30 Jun 2017 23:58:59 -0700] rev 33309
changegroup: don't fail on empty changegroup (API) I don't know why applying an empty changegroup should be an error. It seems harmless. I suspect the check was there to find code that creates empty changegroups just because that would be wasteful. Let's use develwarn() for that instead, so we catch any such cases that run with our test runner, but we still allow others to generate empty changegroups if they want to. We have run into this check at Google once or twice and had to work around it, but I'm changing this not so much because of that, but because it seems like it shouldn't be an error. I also changed the message slightly to be more modern ("changelog group" -> "changegroup") and more generic ("received" -> "applied").
Sat, 01 Jul 2017 00:00:09 -0700 changegroup: remove option to allow empty changegroup (API)
Martin von Zweigbergk <martinvonz@google.com> [Sat, 01 Jul 2017 00:00:09 -0700] rev 33308
changegroup: remove option to allow empty changegroup (API) No caller sets the "emptyok" option, so let's remove it.
Fri, 30 Jun 2017 23:58:31 -0700 strip: don't allow empty changegroup in bundle1
Martin von Zweigbergk <martinvonz@google.com> [Fri, 30 Jun 2017 23:58:31 -0700] rev 33307
strip: don't allow empty changegroup in bundle1 Applying an empty changegroup has been an error since the beginning. The only exception was strip, which would allow to apply an empty changegroup from the temporary bundle. However, the emptyok=True option was only set for bundle1 bundles. In other words, temporary bundle2 bundles would fail if they were empty. Bundle2 has now been used enough that it seems safe to say that we simply don't create bundle2 bundles with empty changegroups. That also suggests that we never create bundle1 bundles with empty changegroups (i.e. empty bundle1 bundles, since bundle1 is just a changegroup), because, AFAICT, the code leading up to the application of the bundle is the same for bundle1 and bundle2. Therefore, let's stop passing emptyok=True, so we more clearly get the same behavior for bundle1 and bundle2.
Thu, 08 Jun 2017 22:49:21 -0700 match: minor cleanups to patternmatcher and includematcher
Martin von Zweigbergk <martinvonz@google.com> [Thu, 08 Jun 2017 22:49:21 -0700] rev 33306
match: minor cleanups to patternmatcher and includematcher The "patterns"/"include" in "patternspat"/"includepat" is redundant, so drop it. Also a "_" prefix since it's "private". Inline the "pm"/"im" variables.
(0) -30000 -10000 -3000 -1000 -300 -100 -10 +10 +100 +300 +1000 +3000 +10000 tip