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.