Merge trees #1389
Merge trees #1389
Conversation
| const git_merge_tree_opts *opts); | ||
|
|
||
| /** | ||
| * Produces a `git_index` from the given `git_merge_index` |
There was a problem hiding this comment.
Maybe add a sentence explaining that the merge index is a superset of what can be stored in the index and this flattens the in-memory merge index data when it's time to write the merge results into the actual index? Just thinking about someone who is coming new to this trying to make out how to use the API.
|
Removed I propose we not take |
|
@arrbee by removing |
| * will track renames. | ||
| * | ||
| * The returned merge_index must be freed explicitly with | ||
| * `git_merge_index_free`. |
|
@vmg thanks - I cleaned up that documentation comment as well as some other names that were still sort of sloppily referring to the late, not-so-great "merge index". Also rebased on latest development. |
| char *ancestor; | ||
| char *ours; | ||
| char *theirs; | ||
| } git_index_name_entry; |
There was a problem hiding this comment.
Some nitpicking: I'd like to have _name and _reuc functions under the sys/ namespace, since they are not supposed to be used by normal index consumers. Can you move them? :)
There was a problem hiding this comment.
@vmg you know I love the picking of nits. They have been moved.
|
lolshipped |
| conflict->their_status == GIT_DELTA_RENAMED) | ||
| return 0; | ||
|
|
||
| ancestor_empty = !GIT_MERGE_INDEX_ENTRY_EXISTS(conflict->ancestor_entry); |
There was a problem hiding this comment.
@ethomson: This variable is set but not used anywhere. Can you double-check please?
I'm trying to break that big nasty merge PR into smaller, more manageable PRs. These two commits will take 2 trees and an optional common ancestor tree, and produce a
git_merge_indexthat represents the changes.A
git_merge_indexis remarkably similar to agit_index, however conflicts are tracked differently. Agit_indexrecords conflicts by filename only, which makes determining what happened during a rename conflict impossible. Agit_merge_index, in contrast, keeps track of the files as they were renamed.Consider that there exists some file where file
A1is renamed toB1in one side andC1in the other, while the fileA2is renamed toA2andA3. The resultantgit_indexwill contain the following entries:A
git_merge_index, however, contains conflict grouped by the conflict instead of by the filename. For example:This has additional data above a
git_merge_indexand is trivially convertable to agit_indexthat would represent the merged output or - like an index - into agit_tree.Looking only at the above example, one could make an argument that we could somehow tie the conflict entries back together using the same algorithm that determined that they were rename conflicts in the first place. Even if you wanted to take the computational hit of recomputing the similarity each time you reload the index (and you probably don't), it's not deterministic.
In a rename 2 -> 1 conflict, for example, the ancestors of the conflict isn't even recorded. Consider files
AandBboth renamed toCin the two branches. The resultant conflicts only show the two sides - presumably as a result of these being treated like add/add conflicts:Further, since core git treats these conflicts as separate between the ours and theirs side, once you began resolving these sides independently, it's still more difficult to pair these sides back up.
Thus, I think it makes more sense to track conflicts as conflicts and not track the conflicts by filename.