|
Size: 812
Comment:
|
Size: 1462
Comment:
|
| Deletions are marked like this. | Additions are marked like this. |
| Line 1: | Line 1: |
| So there are probably a couple steps: | See CopyMergeCases for use cases. |
| Line 3: | Line 3: |
| * get manifests * eliminate unchanged files * detect non-overlapped files (files not in both manifests) * put all "new" files in a "post" list. * go through each remaining file, attempt a merge. * if, while merging, we discover no common ancestor, we've hit a rename. Add the file to the post list. * once we have the post list (and have merged all non-renamed/copied files) we can find all the rename links * find ancestors across renames * do a second pass of 3-way merging * the big open question is do we always want to merge-across-copy or do we want to prompt? (my suspicion is always.) * there's a directory rename detection heuristic that's needed here as well and can be done during the overlap detection |
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. General outline: * 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. * 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 most recent ancestor data as fallback for unpaired files in manifest merging Some thoughts on directory rename detection: * for each manifest, construct a list of dirs * 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 ---- CategoryNewFeatures |
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. General outline:
- 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.
- 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 most recent ancestor data as fallback for unpaired files in manifest merging
Some thoughts on directory rename detection:
- for each manifest, construct a list of dirs
- 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