Developers regularly have to resolve merge conflicts, i.e., two conflicting sets of changes to the same files in different branches. Resolving merge conflicts is tedious and error-prone. It often involves inspecting and deciding about multiple changed files.

Developers resolve merge conflicts by: keeping the local version of the code (KL), keeping the remote version (KL), or manually editing both into a single version (ME). The strategies that are most often selected by developers are KL and KR. However, the majority of existing automated techniques target supporting developers in the ME strategy: merging the local and remote versions.

So, we recently proposed RPredictor, a machine learning-based approach to support developers in choosing how to resolve a conflict (by KL, KR, or ME), by predicting their resolution strategy. RPredictor is particularly useful when it predicts KL or KR, since it could apply the prediction automatically, saving developer effort. In its original design, RPredictor uses a set of \emph{Evolution History Features} ($EHF$s) that capture: the magnitude of the changes in conflict, their evolution, and the experience of the developers involved.

In this paper, we propose a new set of \emph{Branch Edit Features} ($BEF$s), that capture the fine-grained edits that were performed on each branch of the conflict. We evaluate the effectiveness provided by $BEF$s in comparison with $EHF$s, in multiple ways.

The results of our experiments provide multiple lessons. First, $BEF$s provide lower effectiveness (F-score) than $EHF$s. Second, combining $BEF$s with $EHF$s still did not improve the effectivness of $EHF$s, it provided the same f-score. Third, combining $EHFs$ with $BEF_{LI}$ (a subset of $BEF$s) was the feature set that provided highest effectiveness in our experiments, but it only improved $EHF$s by 3 pp. f-score. Fourth, it is not clear whether developers would accept the extra effort required for measuring $BEF_{LI}$ in exchange for such an incremental improvement. Finally, our experiments also share the lesson that some feature sets provided higher C-score (i.e., the safety of the technique’s mistakes) as a trade-off for lower f-scores. This may be valued by some developers and we believe that it should be studied in the future.