Rename Plan

Status: completed.

See CopyMergeCases for use cases.

The use cases indicate two different areas we need to handle renames:

• merge on a file that has been renamed remotely and locally to the same file
• files that have been copied/renamed on one side and possibly modified on the other

The first can be addressed by a rename-aware ancestor algorithm placed in filectx and used by merge3. (implemented)

• create an ancestry graph spanning all the renames in question
• find the roots of the graph
• create a child graph and find the distance from the roots
• visit each node searching for the common ancestor as in revlog.ancestor()

The second operates at the manifestmerge level. (implemented)

• find the ancestor changeset - no renames before this point are interesting
• find all files that aren't paired (local, remote)
• find all historic copies/renames for all unpaired files back to ancestor changeset
• find most recent ancestors between (unpaired local, remote) and (local, unpaired remote)
• use this data for unpaired files when merging

Some thoughts on directory rename detection:

• generate a list of directories for each manifest
• scan the copy map, constructing a directory copy map
• if a directory gets "copied" to two places, remove it from the map
• remove entries in the directory copy map for all directories that still exist
• construct lists of unpaired dirs (local, remote)
• if a rename above moves a file from an unpaired dir elsewhere, it's probably a directory rename
• again, use this data as a fallback for dealing with unpaired files in manifest merging

CategoryOldFeatures