test-histedit: reorder phases test and prepare for more We are going to add a lot regarding phase of test while fixing issue3724. This movement allows to put them after this first phase test.

test-histedit: fix instability creation test The current test does not rewrite anything and therefor does not create any instability. We also clean up the repo state after the test. This required the rebase extension.

histedit: record histedit source (issue3681) Have histedit record the hex of the original changeset as already done by: - graft - commit --amend - rebase My main motivation for adding this is to prevent the creation of obsolescence cycle (see issue3681). Note that commit created during edit are not affected yet.

histedit: factor most commit creation in a function Later commits add two important items to histedit: - Obsolescence cycle prevention - Proper phase conservation Those logics must be applied to all simple operations (pick, edit, mess) and will require verbose code. So we introduce a new function that will provide an entry point for this new. logic. The function build a closure to have a clear distinction between commit arguments and data provided to the function to fulfil its logic.

store: switch to C-based hashed path encoding

pathencode: implement both basic and hashed encoding in C

pathencode: implement hashed encoding in C This will be used by an upcoming patch.

pathencode: implement the "mangling" part of hashed encoding in C This will be used by an upcoming patch.

pathencode: add a SHA-1 hash function This will be used by an upcoming patch. This calls out to the Python hash implementation. An earlier version of this function implemented SHA-1 directly, but the amount of extra code didn't seem like a good tradeoff compared to the small big-picture increase in performance (long paths are uncommon).

store: implement lowerencode in C

hgweb: run with "served" filter This changeset enable the "served" filter on all repo used by hgweb. Hgweb misbehave in a lot of when filtering changeset are present but I do not expect normal people to have secret or obsolete changeset on they server. Misbehavior will be gradually fixed later.

hgweb: walk the graph through the changelog This is necessary to enforce filtering. The result is a bit buggy (may provide less changeset than expected, but it will stop crashing on filtered revision access. Note that changelog.revs can not represents empty iteration like xrange did. So we have to explicitly prevent call when there is nothing to do.

hgweb: use changelog for iteration Iterating through changelog is necessary to enforce filtering.

hgweb: ignore filtered revision in revnav This changeset checks that a revision is known before adding it to the navigation. This will prevent traceback on filtered repository. This changeset result in an incorrect behaviors, Navigation link may be dropped without any replacement. However this bad navigation generation is much better than a crash

hgweb: generate revnav in two phase We first generate revision to link. Then we dispatch them in before, after list. This will help filtering of unknown revision.

rebase: support multiple roots for rebaseset We have all the necessary mechanism to rebase a set with multiple roots, we only needed a proper handling of this case we preparing and concluding the rebase. This changeset des that. Rebase set with multiple root allows some awesome usage of rebase like: - rebase all your draft on lastest upstream hg rebase --dest @ --rev 'draft()' - exclusion of specific changeset during rebase hg rebase --rev '42:: - author(Babar)' - rebase a set of revision were multiple roots are later merged hg rebase --rev '(18+42)::'

clfilter: stronger detection of filtered changeset in changectx.__init__ We previously let some IndexError spill out of this function. A new tests is added to check the command that spotted the error.

validate: check for spurious incoming filelog entries Accepting those will lead to "mild corruption", correctly reported as an error by hg verify, but often not a problem in practice. Enabled when server.validate is switched on.

zsh_completion: add descriptive branch names to head revisions

zsh_completion: add completion of branch names

zsh_completion: fix issue with overlong branch/tag names

bundlerepo: remove old style check of file names The old check is no longer needed: The checked paths will be passed on to filelog.__init__ which will prefix the path with 'data/'. A leading '/' will thus not do any harm. And: The paths will be used by an opener which will use a pathauditor. And finally: The old check did not consider Windows paths and was thus insufficient.

bundlerepo: use revlog._checkhash The error message will mention datafile instead of indexfile.

bundlerepo: store validated deltabase rev in basemap instead of node This avoids some lookups and aligns bundlerepo more with what revlog do.