extract: remove the 'user' variable It is not heavily used enough to justify being something other than a dictionary entry.

extract: use a single return The differences between both returns are now very thin, we factor out that part.

extract: move 'nodeid' assignment where it is parsed The is one setter and no consumer, we can move it there directly.

extract: move 'date' assignment where it is parsed There is one setter and no consumer, we can move it there directly.

extract: assign user to 'data' earlier This is used in both case, we can assign it once.

extract: move 'branch' assignment where it is parsed There is one setter and no consumer, we can move it there directly.

extract: directly assign parent to data dictionary The temporary variables are not adding anything.

extract: assign message only once This return is shared between the two cases. We can move it earlier.

extract: simplify parents assignement We move to the more standard style of: value = default if special: value = other This is more consistent and compact.

patch: move 'extract' return to a dictionnary The final goal here is to be able to parse, return and process arbitrary data from patch. This mirror the recently added ability to add arbitrary data to patch headers. The first step is to return something more flexible, so we return a dict without changing any other logic.

patchbomb: add experimental config of a "pullurl" and export it This config allows to specify a public location where your changeset can be found. It then include a dedicated patch header show a command to be used to retrieve the change. See the test for example. This is flagged as experimental because this feature is not safe until we have more logic to test that: - changeset actually exists on destination - changeset is draft on destination. As all this is experimental, bike shedding can happily happens before we remove the experimental flag.

export: introduce a generic way to add patch header on export Extensions currently have no easy way to add data to exported patch. This is now fixed using a generic mechanism in the same fashion used by bundle2. Tests are coming in the next changeset with its first user.

incoming: request a bundle2 when possible (BC) Incoming was using bundle1 in all cases, as bundle1 is restricted to changegroup1 and does not support general delta, this can lead to significant CPU overhead if the server is using general delta storage. We now properly request and store a bundle2 to disk. If the server include any output or error in the bundle, they will be stored on disk and replayed when the bundle is read. As 'hg incoming' is going to read the bundle right away, we call that 'good' enough and go back to the bigger plan of having general delta on by default. This was tracked as 4864

bundlerepo: indent some code to prepare next patch We are about to add a new condition. Code is indented in a separated patch for readability.

bundle2: add a way to just forward the bundle2 stream to another user There is use case for directly forward and bundle2 stream from the peer to a file (eg: 'hg incoming --bundle'), However ssh peers have no way to know the 'getbundle' is over except for actually interpreting the bundle. So we need to have the unbundle do the interpreting and forward job. The function is marked as private to highlight that this is terrible and that we are sorry.

bundle2: split parameter retrieval and processing We want to introduce a simple way to forward the content of a bundle2 stream. For this purpose, we will need to both yield the parameters block and process it (to apply any behavior change it might indicate).

changegroup: extract the file management part in its own function The current writebundle function do two things: - taking a changegroup-packer instance and storing it into a valid bundle with proper header. - creating a temporary or requested file to store that bundle We would like to make it easier to forward bundle stream directly from a remote peer to a file, so we split the two logic to be able to skip the one about building a valid bundle (the remote is already sending one).

unbundle: properly read head modification result from bundle2 We were reading the wrong key...

revset: strip off "literal:" prefix from bookmark not found error This is what branch() and tag() do.

revset: do not fall through to revspec for literal: branch (issue4838) If "literal:" is specified, it must not be a revset expression. It should error out with a better message.

hgweb: ensure both foreground and background colors are specified (issue4872) When users configure the default foreground or background color to non-default (black on white) values, several hgweb styles lack contrast for headers and table row items. This patch fixes that by ensuring that where either foreground or background colors are specified, both are specified.

templater: do not pre-evaluate generator keyword at runsymbol (issue4868) It was introduced by e06e9fd2d99f, but the important code was removed by a3c2d9211294. So there was no positive effect other than exhausting memory. The problem spotted by e06e9fd2d99f is that you can't use a generator keyword more than once. For example, in hgweb template, "{child} {child}" doesn't work because the first "{child}" consumes the generator. But as a3c2d9211294 says, the fix was wrong because it could overwrite a callable keyword that returns a generator. Also the fix didn't work for a generator of generator such as "{diff}" keyword. So, the proper fix for that problem would be to not put a generator in a keyword table. Instead, it should be a factory of a generator. Note that this should fix the memory issue in hgweb, but my firefox killed by OOM in place. Be careful to not use a modern web browser to test the issue4868.

merge: drop special parent assignment in the obsolete case We can safely drop this because the very same assignment is enforcement later in the function. Dropping it will make it simpler to extract the default destination logic in its own function.

bundle: use bundle2 if repository uses general delta As bundle1 does not support generaldelta, this would mean recomputing delta at bundle time. This is similar to what we do for strip and shelve and was tracked as issue4865.