Understanding semi-structured merge conflict characteristics in open-source Java projects

Accioly, Paola; Borba, Paulo; Cavalcanti, Guilherme

doi:10.1007/s10664-017-9586-1

Cited by 33 publications

(22 citation statements)

References 31 publications

Supporting

Mentioning

Contrasting

Order By: Relevance

“…Cavalcante et al miss information about conflicts that happen inside method bodies, as the semi-structured merge techniques they used treated method bodies as plain text. Accioly et al [45] also studied semi-structured merge, analyzing 70,047 merges from 123 GitHub projects. They found that 87.57% of merge conflicts take place inside the same method and suggest that awareness tools should be used to avoid them.…”

Section: Related Workmentioning

confidence: 99%

On the Nature of Merge Conflicts: A Study of 2,731 Open Source Java Projects Hosted by GitHub

Ghiotto

Murta

Barros

et al. 2020

IIEEE Trans. Software Eng.

View full text Add to dashboard Cite

When multiple developers change a software system in parallel, these concurrent changes need to be merged to all appear in the software being developed. Numerous merge techniques have been proposed to support this task, but none of them can fully automate the merge process. Indeed, it has been reported that as much as 10% to 20% of all merge attempts result in a merge conflict, meaning that a developer has to manually complete the merge. To date, we have little insight into the nature of these merge conflicts. What do they look like, in detail? How do developers resolve them? Do any patterns exist that might suggest new merge techniques that could reduce the manual effort? This paper contributes an in-depth study of the merge conflicts found in the histories of 2,731 open source Java projects. Seeded by the manual analysis of the histories of five projects, our automated analysis of all 2,731 projects: (1) characterizes the merge conflicts in terms of number of chunks, size, and programming language constructs involved, (2) classifies the manual resolution strategies that developers use to address these merge conflicts, and (3) analyzes the relationships between various characteristics of the merge conflicts and the chosen resolution strategies. Our results give rise to three primary recommendations for future merge techniques, that -when implemented -could on one hand help in automatically resolving certain types of conflicts and on the other hand provide the developer with tool-based assistance to more easily resolve other types of conflicts that cannot be automatically resolved.

show abstract

Section: Related Workmentioning

confidence: 99%

On the Nature of Merge Conflicts: A Study of 2,731 Open Source Java Projects Hosted by GitHub

Ghiotto

Murta

Barros

et al. 2020

IIEEE Trans. Software Eng.

View full text Add to dashboard Cite

show abstract

“…The authors also found that the output of semi-structured merge is easier to understand and resolve. In a follow-up work, Accioly et al [4] investigated the structure of code changes that lead to conflicts with semi-structured tools. The study showed that in most of the conflicting merge scenarios, more than two developers are involved.…”

Section: B Empirical Studies On Software Mergingmentioning

confidence: 99%

“…Distributed Version Control Systems (VCSs), such as Git, and social coding platforms, such as GitHub, have made such collaborative software development easier. However, despite its advantages, collaborative software development also gives rise to several issues [1], [2], including merging and integration problems [3], [4].…”

Section: Introductionmentioning

confidence: 99%

Predicting Merge Conflicts in Collaborative Software Development

Owhadi-Kareshk

Nadi

Rubin

2019

2019 ACM/IEEE International Symposium on Empirical Software Engineering and Measurement (ESEM)

View full text Add to dashboard Cite

Background. During collaborative software development, developers often use branches to add features or fix bugs. When merging changes from two branches, conflicts may occur if the changes are inconsistent. Developers need to resolve these conflicts before completing the merge, which is an error-prone and time-consuming process. Early detection of merge conflicts, which warns developers about resolving conflicts before they become large and complicated, is among the ways of dealing with this problem. Existing techniques do this by continuously pulling and merging all combinations of branches in the background to notify developers as soon as a conflict occurs, which is a computationally expensive process. One potential way for reducing this cost is to use a machine-learning based conflict predictor that filters out the merge scenarios that are not likely to have conflicts, i.e. safe merge scenarios.Aims. In this paper, we assess if conflict prediction is feasible.Method. We design a classifier for predicting merge conflicts, based on 9 light-weight Git feature sets. To evaluate our predictor, we perform a large-scale study on 267, 657 merge scenarios from 744 GitHub repositories in seven programming languages.Results. Our results show that we achieve high f1-scores, varying from 0.95 to 0.97 for different programming languages, when predicting safe merge scenarios. The f1-score is between 0.57 and 0.68 for the conflicting merge scenarios.Conclusions. Predicting merge conflicts is feasible in practice, especially in the context of predicting safe merge scenarios as a pre-filtering step for speculative merging.

show abstract

“…With the rise of globally distributed and large software development teams, this adds a layer of complexity due to the fact that developers working on overlapping parts of the same codebase might be in different teams or geographies or both. While such collaborative software development is essential for building complex software systems that meet the expected quality thresholds and delivery deadlines, it may have unintended consequences or "side effects" [1,8,30,36]. The side effects can be as simple as syntactic merge conflicts, which can be handled by version control systems [41] and various techniques/tools [20,26,29], to semantic conflicts [23].…”

Section: Introductionmentioning

confidence: 99%

ConE: A Concurrent Edit Detection Tool for Large-scale Software Development

Maddila

Nagappan

Bird

et al. 2021

ACM Trans. Softw. Eng. Methodol.

View full text Add to dashboard Cite

Modern, complex software systems are being continuously extended and adjusted. The developers responsible for this may come from different teams or organizations, and may be distributed over the world. This may make it difficult to keep track of what other developers are doing, which may result in multiple developers concurrently editing the same code areas. This, in turn, may lead to hard-to-merge changes or even merge conflicts, logical bugs that are difficult to detect, duplication of work, and wasted developer productivity. To address this, we explore the extent of this problem in the pull-request-based software development model. We study half a year of changes made to six large repositories in Microsoft in which at least 1,000 pull requests are created each month. We find that files concurrently edited in different pull requests are more likely to introduce bugs. Motivated by these findings, we design, implement, and deploy a service named Concurrent Edit Detector (ConE) that proactively detects pull requests containing concurrent edits, to help mitigate the problems caused by them. ConE has been designed to scale, and to minimize false alarms while still flagging relevant concurrently edited files. Key concepts of ConE include the detection of the Extent of Overlap between pull requests, and the identification of Rarely Concurrently Edited Files . To evaluate ConE, we report on its operational deployment on 234 repositories inside Microsoft. ConE assessed 26,000 pull requests and made 775 recommendations about conflicting changes, which were rated as useful in over 70% (554) of the cases. From interviews with 48 users, we learned that they believed ConE would save time in conflict resolution and avoiding duplicate work, and that over 90% intend to keep using the service on a daily basis.

show abstract

Understanding semi-structured merge conflict characteristics in open-source Java projects

Cited by 33 publications

References 31 publications

On the Nature of Merge Conflicts: A Study of 2,731 Open Source Java Projects Hosted by GitHub

On the Nature of Merge Conflicts: A Study of 2,731 Open Source Java Projects Hosted by GitHub

Predicting Merge Conflicts in Collaborative Software Development

ConE: A Concurrent Edit Detection Tool for Large-scale Software Development

Contact Info

Product

Resources

About