crecord: edit during hg crecord should preserve cursor position (issue5041) This patch adds a variable to keep track of what hunk was selected before the edit. We use that variable to select the hunk or its replacement after the edit.

templates: use canvaswidth instead of fixed width for canvas (issue2683) Before this patch, template files for "graph" web page use fixed width size "480" for canvas element. This causes pruned lanes and invisible vertexes, if there are 16 or more vertical lanes at once. In such case, part of graph in right side area over 480 is invisible, even though corresponded summary text blocks are visible correctly. This limitation isn't reasonable for workflow using many branches at once (e.g. "one branch per issue" workflow). There were changes below related to width of canvas: - 7359cb753a54 (templates: widen the graph canvas (issue2683)), released as a part of Mercurial 1.8.2 According to the description, this assumed that 15 parallel branches was enough for ordinary workflow, and bumped width of canvas up from 224 to 480. - d490edc71146 (hgweb: make graph data suitable for template usage), released as a part of Mercurial 2.3 This introduced "canvaswidth" template keyword as a part of refactoring around graph rendering. But 'width="480"' of canvas element in template files wasn't replaced by 'width="{canvaswidth}"' in it (or subsequent one). This patch uses dynamic value "{canvaswidth}" instead of fixed width size "480" for canvas element. This is posted for "stable", because: - this is re-fixing issue2683 - this is simple enough for stable - using "{canvaswidth}" doesn't require any additional cost Calculation of canvaswidth is already implied as a part of "graph" web command.

backout: fix --no-commit option (issue5054)

bundle: exit early when there are no commits to bundle Previously, if you passed a revset that resolved to no nodes, it would get interpreted by the changegroup discovery logic as 'bundle all my heads', which is not what the user asked. Let's exit early when we notice this case. It could be argued that the changeset discovery logic should be smarter and only assume 'all heads' if the incoming heads parameter is None, but that's a much riskier change.