Sun, 12 Oct 2014 08:03:20 -0700 phases: inform transaction-related hooks that a phase was moved
Pierre-Yves David <pierre-yves.david@fb.com> [Sun, 12 Oct 2014 08:03:20 -0700] rev 22940
phases: inform transaction-related hooks that a phase was moved We do not have enough information to provide finer data, but this is still useful information.
Mon, 13 Oct 2014 14:52:38 -0700 test-bundle2: also test the argument of the changegroup hook
Pierre-Yves David <pierre-yves.david@fb.com> [Mon, 13 Oct 2014 14:52:38 -0700] rev 22939
test-bundle2: also test the argument of the changegroup hook We also track execution of the changegroup hook. The important information here is to make sure the information that the transaction was processing a bundle2 is passed to hook. This will let most hooks disable themselves while waiting for the hook concluding bundle2 processing (the one we discovered to be not called for pull in the previous changesets).
Mon, 13 Oct 2014 14:47:36 -0700 test-bundle2: test that we got appropriate hook called with appropriate data
Pierre-Yves David <pierre-yves.david@fb.com> [Mon, 13 Oct 2014 14:47:36 -0700] rev 22938
test-bundle2: test that we got appropriate hook called with appropriate data We can notice that this transaction wide hook is only happening during push and it is missing changegroup-related information. We'll want to fix this but this is not what this patch is about.
Sun, 12 Oct 2014 06:40:36 -0700 pull: use `stepsdone` instead of `todosteps`
Pierre-Yves David <pierre-yves.david@fb.com> [Sun, 12 Oct 2014 06:40:36 -0700] rev 22937
pull: use `stepsdone` instead of `todosteps` The push process uses a `stepsdone` attribute instead of a `todosteps` one (with the logic swapped). We unify the two process by picking the `stepsdone` version. I feel like `stepsdone` better fits extensions that would want to extend the push exchange process.
Sat, 27 Sep 2014 00:29:06 -0700 pull: make discovery phase extensible
Pierre-Yves David <pierre-yves.david@fb.com> [Sat, 27 Sep 2014 00:29:06 -0700] rev 22936
pull: make discovery phase extensible We apply the same approach as for push and make the discovery extensible. There is only one user in core right now, but we already know we'll need something smarter for obsmarkers. In fact the evolve extension could use this to cleanly extend discovery. The main motivation for this change is consistency between push and pull.
Tue, 14 Oct 2014 21:59:39 +0900 sshpeer: forward stdout of remote "hg init" to appropriate output channel
Yuya Nishihara <yuya@tcha.org> [Tue, 14 Oct 2014 21:59:39 +0900] rev 22935
sshpeer: forward stdout of remote "hg init" to appropriate output channel Otherwise, commandserver channel could be corrupted.
Wed, 03 Sep 2014 16:34:29 -0400 revlog: support importing censored file revision tombstones
Mike Edgar <adgar@google.com> [Wed, 03 Sep 2014 16:34:29 -0400] rev 22934
revlog: support importing censored file revision tombstones This change allows a revision log to not fail integrity checks when applying a changegroup delta (eg from a bundle) results in a censored file tombstone. The tombstone is inserted as-is, so future integrity verification will observe the tombstone. Deltas based on the tombstone will also remain correct. The new code path is encountered for *exactly* the cases where _addrevision is importing a tombstone from a changegroup. When committing a file containing the "magic" tombstone text, the "text" parameter will be non-empty and the checkhash call is not executed (and when committing, the node will be computed to match the "magic" tombstone text).
Tue, 14 Oct 2014 16:16:04 -0400 verify: report censored nodes if configured policy is abort
Mike Edgar <adgar@google.com> [Tue, 14 Oct 2014 16:16:04 -0400] rev 22933
verify: report censored nodes if configured policy is abort
Tue, 14 Oct 2014 15:46:16 -0400 context: handle censored data in an on-disk file context based on config
Mike Edgar <adgar@google.com> [Tue, 14 Oct 2014 15:46:16 -0400] rev 22932
context: handle censored data in an on-disk file context based on config Two possible behaviors are defined for handling censored data: abort, and ignore. When we ignore censored data we return an empty file to callers requesting the file data.
Wed, 08 Oct 2014 15:20:14 -0400 manifest: add fastdelta method to manifestdict
Augie Fackler <raf@durin42.com> [Wed, 08 Oct 2014 15:20:14 -0400] rev 22931
manifest: add fastdelta method to manifestdict This is another step closer to alternate manifest implementations that can offer different hashing algorithms.
Wed, 08 Oct 2014 15:21:59 -0400 manifest: move _search to module level and rename to _msearch
Augie Fackler <raf@durin42.com> [Wed, 08 Oct 2014 15:21:59 -0400] rev 22930
manifest: move _search to module level and rename to _msearch The rename is intended to provide a slight hint that it is manifest-specific.
Wed, 08 Oct 2014 14:47:30 -0400 manifest: move manifestdict-to-text encoding to manifest class
Augie Fackler <raf@durin42.com> [Wed, 08 Oct 2014 14:47:30 -0400] rev 22929
manifest: move manifestdict-to-text encoding to manifest class A future patch will introduce a new format, with a new class.
Fri, 03 Oct 2014 13:22:31 -0700 localrepo: access status fields by name rather than index
Martin von Zweigbergk <martinvonz@gmail.com> [Fri, 03 Oct 2014 13:22:31 -0700] rev 22928
localrepo: access status fields by name rather than index
Sat, 11 Oct 2014 22:43:14 -0700 subrepo: use separate instances of empty lists in status
Martin von Zweigbergk <martinvonz@gmail.com> [Sat, 11 Oct 2014 22:43:14 -0700] rev 22927
subrepo: use separate instances of empty lists in status We do modify the lists that make up the status in several places, so it seems risky to use the same instance of a list for several different status types. Use a separate empty list for each type instead.
Fri, 03 Oct 2014 09:29:48 -0700 summary: make status code more readable
Martin von Zweigbergk <martinvonz@gmail.com> [Fri, 03 Oct 2014 09:29:48 -0700] rev 22926
summary: make status code more readable In commands.summary(), we currently zip a list of labels with a list of statuses. This means the order of the status list has to match the list of the labels, which in turn means the status elements have to be inserted into specific places in the list. Let's instead group the labels and status data we want to display in a single list of pairs.
Sat, 04 Oct 2014 20:53:05 -0700 strip: make checklocalchanges() return full status tuple
Martin von Zweigbergk <martinvonz@gmail.com> [Sat, 04 Oct 2014 20:53:05 -0700] rev 22925
strip: make checklocalchanges() return full status tuple By making checklocalchanges() return the full instance of the status class instead of just the first 4 elements of it, we can take advantage of the field names and not require the caller to remember the element indices.
Sat, 04 Oct 2014 21:58:01 -0700 fileset: access status fields by name rather than index
Martin von Zweigbergk <martinvonz@gmail.com> [Sat, 04 Oct 2014 21:58:01 -0700] rev 22924
fileset: access status fields by name rather than index
Sat, 04 Oct 2014 21:19:44 -0700 histedit: access status fields by name rather than index
Martin von Zweigbergk <martinvonz@gmail.com> [Sat, 04 Oct 2014 21:19:44 -0700] rev 22923
histedit: access status fields by name rather than index
Fri, 03 Oct 2014 22:12:43 -0700 shelve: access status fields by name rather than index
Martin von Zweigbergk <martinvonz@gmail.com> [Fri, 03 Oct 2014 22:12:43 -0700] rev 22922
shelve: access status fields by name rather than index
Fri, 03 Oct 2014 10:44:07 -0700 record: access status fields by name rather than index
Martin von Zweigbergk <martinvonz@gmail.com> [Fri, 03 Oct 2014 10:44:07 -0700] rev 22921
record: access status fields by name rather than index It is safe to pass the full status to patch.diff() since it does its own slicing.
Fri, 03 Oct 2014 10:38:43 -0700 purge: access status fields by name rather than index
Martin von Zweigbergk <martinvonz@gmail.com> [Fri, 03 Oct 2014 10:38:43 -0700] rev 22920
purge: access status fields by name rather than index
Fri, 03 Oct 2014 22:10:08 -0700 largefiles: access status fields by name rather than index
Martin von Zweigbergk <martinvonz@gmail.com> [Fri, 03 Oct 2014 22:10:08 -0700] rev 22919
largefiles: access status fields by name rather than index
Fri, 03 Oct 2014 10:05:54 -0700 keyword: access status fields by name rather than index
Martin von Zweigbergk <martinvonz@gmail.com> [Fri, 03 Oct 2014 10:05:54 -0700] rev 22918
keyword: access status fields by name rather than index
Fri, 03 Oct 2014 09:51:39 -0700 hgcia: access status fields by name rather than index
Martin von Zweigbergk <martinvonz@gmail.com> [Fri, 03 Oct 2014 09:51:39 -0700] rev 22917
hgcia: access status fields by name rather than index
Sat, 04 Oct 2014 21:05:41 -0700 context: store status class instead of plain tuple in self._status
Martin von Zweigbergk <martinvonz@gmail.com> [Sat, 04 Oct 2014 21:05:41 -0700] rev 22916
context: store status class instead of plain tuple in self._status This improves readability a bit by allowing us to refer to statuses by name rather than index.
Fri, 10 Oct 2014 10:14:35 -0700 status: update and move documentation of status types to status class
Martin von Zweigbergk <martinvonz@gmail.com> [Fri, 10 Oct 2014 10:14:35 -0700] rev 22915
status: update and move documentation of status types to status class The various status types are currently documented on the dirstate.status() method. Now that we have a class for the status types, it makese sense to document the status types there instead. Only leave the bits related to lookup/unsure in the status() method documentation.
Tue, 14 Oct 2014 00:52:27 -0500 status: update various other methods to return new class
Martin von Zweigbergk <martinvonz@gmail.com> [Tue, 14 Oct 2014 00:52:27 -0500] rev 22914
status: update various other methods to return new class
Fri, 10 Oct 2014 14:32:36 -0700 status: create class for status lists
Martin von Zweigbergk <martinvonz@gmail.com> [Fri, 10 Oct 2014 14:32:36 -0700] rev 22913
status: create class for status lists Callers of various status() methods (on dirstate, context, repo) get a tuple of 7 elements, where each element is a list of files. This results in lots of uses of indexes where names would be much more readable. For example, "status.ignored" seems clearer than "status[4]" [1]. So, let's introduce a simple named tuple containing the 7 status fields: modified, added, removed, deleted, unknown, ignored, clean. This patch introduces the class and updates the status methods to return instances of it. Later patches will update the callers. [1] Did you even notice that it should have been "status[5]"? (tweaked by mpm to introduce the class in scmutil and only change one user)
Fri, 03 Oct 2014 21:21:20 -0700 lfutil: avoid creating unnecessary copy of status tuple
Martin von Zweigbergk <martinvonz@gmail.com> [Fri, 03 Oct 2014 21:21:20 -0700] rev 22912
lfutil: avoid creating unnecessary copy of status tuple In lfdirstatestatus(), the status tuple gets deconstructed, the lists get updated, and then an identical status tuple gets created and returned. Change it so we simply return the original tuple.
Fri, 03 Oct 2014 21:44:10 -0700 dirstate: separate 'lookup' status field from others
Martin von Zweigbergk <martinvonz@gmail.com> [Fri, 03 Oct 2014 21:44:10 -0700] rev 22911
dirstate: separate 'lookup' status field from others The status tuple returned from dirstate.status() has an additional field compared to the other status tuples: lookup/unsure. This field is just an optimization and not something most callers care about (they want the resolved value of 'modified' or 'clean'). To prepare for a single future status type, let's separate out the 'lookup' field from the rest by having dirstate.status() return a pair: (lookup, status).
Mon, 13 Oct 2014 14:18:47 -0700 commit: update file nodeid and flags in the same place
Martin von Zweigbergk <martinvonz@gmail.com> [Mon, 13 Oct 2014 14:18:47 -0700] rev 22910
commit: update file nodeid and flags in the same place Now that we have a separate variable for the original 'm1' manifest, we can safely update the nodeid of the file in the new manifest in the same place as we update the flags.
Mon, 13 Oct 2014 14:11:47 -0700 commit: use separate variable for p1 manifest and new manifest
Martin von Zweigbergk <martinvonz@gmail.com> [Mon, 13 Oct 2014 14:11:47 -0700] rev 22909
commit: use separate variable for p1 manifest and new manifest In localrepo.commitctx(), p1's manifest is copied and used as the basis for the manifest that is about to be committed. The way the copy is updated makes it safe to use it where the original p1's manifest is wanted. For readability, though, a separate variable for each purpose would be clearer. Make it so.
Mon, 13 Oct 2014 14:34:53 -0700 commit: remove dead initialization of 'lock'
Martin von Zweigbergk <martinvonz@gmail.com> [Mon, 13 Oct 2014 14:34:53 -0700] rev 22908
commit: remove dead initialization of 'lock' The 'lock' variable is initialized to None, but before it's ever read, it's assigned again.
Mon, 13 Oct 2014 16:43:37 -0700 commit: reduce scope of 'removed' variable
Martin von Zweigbergk <martinvonz@gmail.com> [Mon, 13 Oct 2014 16:43:37 -0700] rev 22907
commit: reduce scope of 'removed' variable The variable is closely related to 'added' and 'changed', so it makes sense to have it declared next to them.
Mon, 13 Oct 2014 18:00:39 -0500 rebase: fix some weird mixed-case naming
Matt Mackall <mpm@selenic.com> [Mon, 13 Oct 2014 18:00:39 -0500] rev 22906
rebase: fix some weird mixed-case naming
Mon, 13 Oct 2014 17:55:45 -0500 rebase: move duplicatecopies next to merge
Matt Mackall <mpm@selenic.com> [Mon, 13 Oct 2014 17:55:45 -0500] rev 22905
rebase: move duplicatecopies next to merge This is preparation for removing open-coded rebase/graft operations. As a side-effect, this exposes proper renames in the working copy when there are conflicts, which shows up in test-shelve.t.
Mon, 13 Oct 2014 17:12:47 -0500 histedit: use merge.graft
Matt Mackall <mpm@selenic.com> [Mon, 13 Oct 2014 17:12:47 -0500] rev 22904
histedit: use merge.graft
Mon, 13 Oct 2014 17:12:31 -0500 graft: use merge.graft
Matt Mackall <mpm@selenic.com> [Mon, 13 Oct 2014 17:12:31 -0500] rev 22903
graft: use merge.graft
Mon, 13 Oct 2014 17:12:12 -0500 merge: add merge.graft helper
Matt Mackall <mpm@selenic.com> [Mon, 13 Oct 2014 17:12:12 -0500] rev 22902
merge: add merge.graft helper This will help unify all the open-coded graft/rebase operations.
Mon, 13 Oct 2014 14:33:13 -0500 duplicatecopies: move from cmdutil to copies
Matt Mackall <mpm@selenic.com> [Mon, 13 Oct 2014 14:33:13 -0500] rev 22901
duplicatecopies: move from cmdutil to copies This is in preparation for moving its primary caller into merge.py, which would be a layering violation in the current location.
Mon, 13 Oct 2014 14:04:11 -0500 histedit: fix indent
Matt Mackall <mpm@selenic.com> [Mon, 13 Oct 2014 14:04:11 -0500] rev 22900
histedit: fix indent The duplicatecopies call should be part of the rebase block.
Mon, 13 Oct 2014 13:21:03 -0500 graft: move rebase cleanup code next to actual rebase
Matt Mackall <mpm@selenic.com> [Mon, 13 Oct 2014 13:21:03 -0500] rev 22899
graft: move rebase cleanup code next to actual rebase This is prep for refactoring the rebase logic.
Fri, 10 Oct 2014 13:44:40 -0500 shelve: add a bundlerepo method
Matt Mackall <mpm@selenic.com> [Fri, 10 Oct 2014 13:44:40 -0500] rev 22898
shelve: add a bundlerepo method
Sat, 11 Oct 2014 14:05:09 -0500 dirstate: merge falls through to otherparent
Matt Mackall <mpm@selenic.com> [Sat, 11 Oct 2014 14:05:09 -0500] rev 22897
dirstate: merge falls through to otherparent This lets us more correctly fix the state when we use setparents, as demonstrated in the change in test-graft.t.
Fri, 10 Oct 2014 13:31:06 -0500 dirstate: use 'm' state in otherparent to reduce ambiguity
Matt Mackall <mpm@selenic.com> [Fri, 10 Oct 2014 13:31:06 -0500] rev 22896
dirstate: use 'm' state in otherparent to reduce ambiguity In rebase-like operations where we abandon the second parent, we can correctly fix up the state in setparents.
Fri, 10 Oct 2014 13:05:50 -0500 dirstate: properly clean-up some more merge state on setparents
Matt Mackall <mpm@selenic.com> [Fri, 10 Oct 2014 13:05:50 -0500] rev 22895
dirstate: properly clean-up some more merge state on setparents
Tue, 07 Oct 2014 11:42:37 -0700 phases: move root phase assignment to it's own function
Durham Goode <durham@fb.com> [Tue, 07 Oct 2014 11:42:37 -0700] rev 22894
phases: move root phase assignment to it's own function This moves the initial root phase assignment to it's own function. Future patches which make phase calculations lazy will use this function to pre-fill certain phases which can be deduced from the roots.
Tue, 07 Oct 2014 11:37:54 -0700 phases: add invalidate function
Durham Goode <durham@fb.com> [Tue, 07 Oct 2014 11:37:54 -0700] rev 22893
phases: add invalidate function Phase cache invalidation was spread all over the place. Let's add a function to unify it. Later more will be added to this function.
Sun, 12 Oct 2014 23:30:04 -0700 phases: change phase command change detection
Durham Goode <durham@fb.com> [Sun, 12 Oct 2014 23:30:04 -0700] rev 22892
phases: change phase command change detection A future patch is going to make phase computation lazy, so the phase command can no longer read and diff the entire phase list directly. This changes the phase command to build it's own list for diff purposes.
Fri, 10 Oct 2014 13:09:22 -0700 spanset: remove `.set()` definition
Pierre-Yves David <pierre-yves.david@fb.com> [Fri, 10 Oct 2014 13:09:22 -0700] rev 22891
spanset: remove `.set()` definition All my friends are dead.
Fri, 10 Oct 2014 13:08:49 -0700 generatorset: remove `.set()` definition
Pierre-Yves David <pierre-yves.david@fb.com> [Fri, 10 Oct 2014 13:08:49 -0700] rev 22890
generatorset: remove `.set()` definition All my friends are dead.
Fri, 10 Oct 2014 13:08:28 -0700 addset: remove `.set()` definition
Pierre-Yves David <pierre-yves.david@fb.com> [Fri, 10 Oct 2014 13:08:28 -0700] rev 22889
addset: remove `.set()` definition All my friends are dead.
Fri, 10 Oct 2014 13:08:10 -0700 filteredset: remove `.set()` definition
Pierre-Yves David <pierre-yves.david@fb.com> [Fri, 10 Oct 2014 13:08:10 -0700] rev 22888
filteredset: remove `.set()` definition All my friends are dead.
Fri, 10 Oct 2014 13:07:35 -0700 baseset: remove `set()` definition
Pierre-Yves David <pierre-yves.david@fb.com> [Fri, 10 Oct 2014 13:07:35 -0700] rev 22887
baseset: remove `set()` definition All my friends are dead.
Fri, 10 Oct 2014 11:27:57 -0700 abstractsmartset: remove `set()` method definition
Pierre-Yves David <pierre-yves.david@fb.com> [Fri, 10 Oct 2014 11:27:57 -0700] rev 22886
abstractsmartset: remove `set()` method definition Now that all usages have been removed, we can drop this not so useful part of the API. We can note that the name was wrong all along...
Fri, 10 Oct 2014 14:27:05 -0700 match: check if an object is a baseset using `isascending` instead of `set`
Pierre-Yves David <pierre-yves.david@fb.com> [Fri, 10 Oct 2014 14:27:05 -0700] rev 22885
match: check if an object is a baseset using `isascending` instead of `set` The `set()` method is going away.
Fri, 10 Oct 2014 14:22:23 -0700 getset: check if an object is a baseset using `isascending` instead of `set`
Pierre-Yves David <pierre-yves.david@fb.com> [Fri, 10 Oct 2014 14:22:23 -0700] rev 22884
getset: check if an object is a baseset using `isascending` instead of `set` The `set()` method is going away.
Fri, 10 Oct 2014 13:24:57 -0700 fullreposet: detect smartset using "isascending" instead of "set"
Pierre-Yves David <pierre-yves.david@fb.com> [Fri, 10 Oct 2014 13:24:57 -0700] rev 22883
fullreposet: detect smartset using "isascending" instead of "set" The `.set()` function is going away.
Fri, 10 Oct 2014 13:21:05 -0700 fullreposet: drop custom sets but not smartsets detection
Pierre-Yves David <pierre-yves.david@fb.com> [Fri, 10 Oct 2014 13:21:05 -0700] rev 22882
fullreposet: drop custom sets but not smartsets detection All custom classes use by revsets are smartsets now. We drop the special-casing.
Fri, 10 Oct 2014 12:30:00 -0700 addset: drop `.set()` usage during iteration
Pierre-Yves David <pierre-yves.david@fb.com> [Fri, 10 Oct 2014 12:30:00 -0700] rev 22881
addset: drop `.set()` usage during iteration We can use the containment check directly.
(0) -10000 -3000 -1000 -300 -100 -60 +60 +100 +300 +1000 +3000 +10000 tip