Size: 1462
Comment:
|
Size: 1719
Comment:
|
Deletions are marked like this. | Additions are marked like this. |
Line 1: | Line 1: |
This is mostly complete except for directory rename detection. |
|
Line 8: | Line 10: |
The first can be addressed by a rename-aware ancestor algorithm placed in filectx and used by merge3. General outline: | The first can be addressed by a rename-aware ancestor algorithm placed in filectx and used by merge3. (implemented) |
Line 15: | Line 17: |
The second operates at the manifestmerge level. | The second operates at the manifestmerge level. (implemented) |
Line 21: | Line 23: |
* use most recent ancestor data as fallback for unpaired files in manifest merging | * use this data for unpaired files when merging |
Line 25: | Line 27: |
* for each manifest, construct a list of dirs | * 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 |
This is mostly complete except for directory rename detection.
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