[PATCH] convert: filemap must preserve fast-forward merges (issue3340)

[Matt Mackall]

On Sun, 2012-05-27 at 19:58 +0200, Patrick Mezard wrote:
> # HG changeset patch
> # User Patrick Mezard <patrick at mezard.eu>
> # Date 1338141206 -7200
> # Branch stable
> # Node ID db0660915e353f8a87ed11fb87660a794c0bab45
> # Parent  30e46d7138de0acb2d811162c1cf3441afe1687e
> convert: filemap must preserve fast-forward merges (issue3340)
> 
> When running convert with a filemap, revisions which changes were
> filtered out and not closing branch were discarded. Unfortunately, this
> also discards fast-forward merges between named branches, which are
> fairly important, especially for head revisions.
> 
> This patch makes --filemap preserve fast-forward merges between distinct
> named branches, even if the merge brings nothing but a branch switch,
> and even if the empty merge comes from ancestors being filtered by the
> filemap.

(Kevin's right that this is the opposite of a fast-forward merge.)

In general, I think we need to preserve merges, as they change the
overall topology of the DAG significantly. If we have a DAG that looks
like:

-o-a1-a2-a3...-m-
  \           /
   b1-b2-b3...

..we can drop/fold just about any number of a or b commits, but dropping
o or m will be an issue. But, if we drop all of either b or a, then it's
fine to drop m too. In that case, m's second parent would be o, an
ancestor of the first, an edge we consider redundant.

When named branches come in, we have two cases:

-o-a1-a2-a3...-m-  <- A
  \           /
   b1-b2-b3...     <- B

-o-a1-a2-a3...     <- A
  \           \
   b1-b2-b3...-m-  <- B

If we drop all the bs, we can drop m in the first case, but not in the
second, because m's branch name should be B.

-- 
Mathematics is the supreme nostalgia of our time.