68 KiB
WizardMerge Research Paper
Extracted via OCR from paper pages in docs/pages/
Note: This document contains OCR-extracted text which may have some errors. The original page images are preserved in docs/pages/ for reference. For critical information, please refer to the original images or the published paper.
Page 1
Jul 2024
3
SE]
rXiv:2407.02818v1 [c
WizardMerge - Save Us From Merging Without Any Clues
QINGYU ZHANG, The University of Hong Kong, China JUNZHE LI, The University of Hong Kong, China
JIAYI LIN, The University of Hong Kong, China
JIE DING, The University of Hong Kong, China
LANTENG LIN, Beijing University of Posts and Telecommunications, China CHENXIONG QIAN’, The University of Hong Kong, China
Modern software development necessitates efficient verson-orente collaboration among developers, While Gite the most popular version control system, it generates unsatisfactory version merging results due to textual-based workflow, leading to potentially ‘unexpected results in the merged version of the project. Although mumercus merging tals have ben proposed for improving merge results, developers remain struggling to reslve the conflicts and fix incorrectly modified code without cues, We present WizaxnMaxc, an auxiary tol tha leverages merging results from Git to retrieve code black dependency on text and LLVMAR level and provide suggestions for developers to reeolre errors introduced by textual merging, Through the evaluation, we subjected WizannMenoe to testing on 227 conflicts within five large-scale projects. The outcomes demonstrat that WazannMence diminishes confict merging time costs, achieving a 28.85% reduction. Beyond addressing conflicts, WizanpMancx provides merging suggestions for over 70% of the code blocks potentially affected bythe conflicts Notably, WizarnMancr exhibits the capability to entify confic-umelted cade ‘blocks that require manual intervention yet are hamnfally aplie by Git during the merging.
(CCS Concepts: «Software and its engineering + Software configuration management and version control systems; Auto- ‘mated static analysis; Theory of computation —+ Program analysis.
Additional Key Words and Phrases: Version contrl, Code merging Static analysis
ACM Reference Format: (Qingyu Zhang, Joke Li, Jai Lin, le Ding, Lanteng Lin and Chenxiong Qian, 2024, WinardMerge- Save Us From Merging Without Ay Ches. 1, 1 Quly 2024), 29 pages. htps/dol-org/10.145/nnnnoan.nnnnmn
1 Introdu
[As the most globally renowned version contro system, Git [17] has been helping withthe development and maintenance cof millions of project. To automatically merge the codes from two different version, Git utilizes a Three-way Merge Algorithm [12] a the default strategy on the text level. The textual-based merging is general and suitable for various
*Cormapending author
‘Atha Contac Ifomation Qingy Zhang, The Univers of Hong Kong, HongKong, China stanqy@eomnecthku bk; unbe Li, Tthe University HongKong, Hong Kong, hin, icant say Lin, The Univers of Hong Kong Heng Kan, chi inyOl@cennet bleh e Ding, “The Unbrerety of Hang Keg, Hong Kong, Chin, ing 9455 ilo com: Lanteng Lin, eng Unters of Pst and Teecommunitions, Being Chins ntern@bupt dc; Chemcong Qin, The Unitersty af Hang Kang, Hang Kong Chia cance
‘Permission tombe dgtlorkar copes flr pr this wor for personal or hasrom te i granted without fe provided hat copies are not made or dt far profit commercial advntge and tht cope er thine andthe full tation on the it page Copyright fer component cfthiewodk avnedby others than the author) mart be honored. Abtacting with cei ie permite. To copy other, or epblih 0 pst server orto redtubate oli, egies Prior spec pemisinanl/or ee. aque permission fom peminionn@acm or
(0202 Copyright ld by the owner euthor)- Publi ight een ACM.
Manusrpt bite ACM
Manwsrpt abit ACM 1
Page 2
2 Qingyu Zhang, Junzhe Li, Jiayi Lin, Jie Ding, Lanteng Lin, and Cheniong Qian
types of textiles and the merging tempois proved tobe the fastest. However it simply considealine of code neglecting all yntax and semantic information, which leads to potential bug in the menged version ofthe project [2,26]
“Tomitigste the shor comingsof traditional textual based merging, multiple merging approsches[4, 523,24, 25,4445] ae proposed for enhancing the correctness of merging result. These tocs can be clasifed as Structured Merging and Semi-structured Merging. Structured merging tools [23 25, 4,45] transform the code intended for merging into an Abstract Syntax Tre (AST), thereby converting the code merging into the merging of edges and nodes onthe AST [1] Semi-structured merging [4, 5,24], akin to structured menging, designates certain semantically insensitive AST nodes (eg stings) as text allowing them tobe directly processed bythe text-based merging trtegy during the merging process}
Despite structured and semi-structured merging tools facilitating code merging, challenges arte when it is unclear ‘which version ofthe code should take precedence. This uncertainty leads to merging confit. In the context of large- scale software projects, conflicts can become a source of frustration for developers, as they must dedicate significant effort to resolve the inns that arise from merging before they can releat the inal merged version [2,22]. Addressing these conflict reslutionshas given rise to merging assistance systems, These systems are designed with objectives ach ss sclecting the most auitable developers to resolve conflicts (7, prioritizing the resohiton order for conflicts [23nd ven automatically generating alterative conflict reachtions [44]. With the rapid advancements in machine learning technologie in recent year, researchers have turned to machine leaning approaches [3, 11-13, 15,342]. These systems ae trained using extensive datasets containing merge conflict aenatios and can provide predictions onthe
most suitable resolution strategy for each conflicting portion of code.
While these researches have made noteworthy contributions to code merging, they still exhibit the following limitations. Firstly, structured [4, 23, 35, 44, 45] and semi-structured [5, 34] still generate conflicts when the direct merging between two AST noes filed, and cannot assist developers in resolving them. Secondly, conflict resolution assistance systems [9, 38, 44] focus solely on resolving conflicts, overlooking potential errors introduced by incorrectly applied but confit-fice code. Though machine learning approaches [3, 11, 12, 15,38, 43] can automate conflict merging, the functionality of the resulting code may not ensure alignment with developers’ expectations. Additionally, machine learning methods necessitate specific code datasets for pre-training, which raises universality issues when applied to more diverse code projects. Moreover, the developers often have unpredictable operations on resolving conflicts, where
the auto-generated conic resolution may fil to meet the expectations of them. ‘To address these Imitations, we introduce novel approach aiming to aid developers in handling complex code- merging scenarios. Recognizing that developers have unpredictable ultimate needs, our approach focuses on rouping conflicts by elevance and providing prioritized suggestion for resolving conflict rather than resolving them directly. Our approach also detect the incorrectly applied codes as they can he easily neglected but cumbersome to Dhan for developers To realize these design goals, cur approach requires a thorough understanding ofthe dependency relations in the two merging candidate versions. Firstly, we perform definition dependency graph constuction on LIVM Intermediate Representation (IR) [25] and ullize definition indicators extracted from Clang [25] to indicate the definition name and ranges in the source file. Following graph construction, our approach analyzes the Git merge outcomes that present all the conflicts and modifed code blocks. Then, we align the definitions in the source Se with code snippets in Git's outcomes to map from LLVMIR to the Git merge results. Given the dependency graph analysis nd aligned Git merge results, we further conduct an edge-tenstive algorithm to detect incomecty applied codes, which wwe deem a conflicts since they require developer atenton as wel. nally, we assign priorities to these conilcted nodes and produce merging suggestions Manu beiteo ACM.
Page 3
WizardMerge - Save Us From Merging Without Any Clues 3
We implement a prototype WiZARDMERGE for C/C++ projects ae most large-scale projects are written in C/C++ [20]. We evaluate WizanDMERGE on 227 conflicts from five popular large projects. The outcomes demonstrate that Wiz- ARDMENGE diminishes conflict merging time costs. Beyond addressing conflicts, WIZARDMERGE provides merging suggestions for most of the code blocks affected by the conflicts, Moreaver, WiZARDMERGE exhibits the capability to identify conflct-unrelated code blocks which should require manual intervention yet automatically applied by Git. In summary, we make the following contributions: ‘© We proposed a novel approach to infer the dependency between text-level code blocks with modification, ‘¢ We proposed a remarkable methodology, which aims to pinpoint code blocks that have been automatically applied by Git but introduce unexpected results, ‘© We implemented a code merging auxiliary prototype named W1zannMencx based on the approaches and evaluated ‘the system on projects with large-scale code bases. We will open source WiZARDMERGE and evahuation datascts at Ittpes//github.com/aa/bb,
- Background
- Git Merging
Variant A_(VA) Base Variant B_(VB) Tine | we = Stmea0p Vi = Semis Vi = Stati()3 Line 2| Wi-= Semt2(07 V5 Va = Semt2(VA)y VE = Stat 2(VATy Line | “Wa= seme (v2) V3 = Semt3(Vi, V2)p VS Stat9(Vi, V2)p “Line 4| V3-= Stme3(Vi, V2)p Var = Semt2(V2)3 V5-= Stat a(V2, V3)5 Line | -W5-= Stmea(v2, V3); Vs = Stata(v2, V3)z Ve = Stat5 (Vi) Line 6| We= Seat5(Vi)3 Ve = Stmt5(VI)y We si 2(5)y (Zine | WWrs See, Wey] 0e =o [V7 = Sem (V6); ‘Merged Commit Va = Semi; a & [rs seme2(2y5 | — Vas Sem 2(V2)5 ! fo Fis sea | [v5 semea(v2, va); —| | Ve = Sem5(VI); Developer
Fig. 1. Three-way merging workflow of Git
Git is a free and open-source distributed version control system designed for eficent handling of projects ofall sizes [17] Git merge, as a key operation, facilitates the integration of changes between versions and is often ured to consolidate code changes, bug fixes, or new features [18]. Git supports multiple textual-based merging algorithms [7]. ‘Take the default and most commonly employed algorithm, Three-way Merging Algorithm [42] as an example, the ‘worlllow is shown in Figure 1. When the developer tres to merge two commits (ie, Cs Variant A (VA) and Cs Vai B (VB) inFigure 1), Gt first travertes the commit-graph back until it reaches the nearest common ancestor commit (i.e, Cz,mamed Base). Then, all source code blocks of each newer version are mapped to the corresponding code blocks in base versions, and the modified code blocks of either VA or VB are regarded as Diff Code Blocks (DCBs). A DCB in a
Manat submited to ACM.
Page 4
4 Qingyu Zhang, Junzhe Li, Jiayi Lin, Jie Ding, Lanteng Lin, and Cheniong Qian
variant may contain zero or multiple lines of code, indicating the removal ofan existing line or modification/addition of ‘multiple continuous lines. ARer the code matching stage, Git will iterate each code block tuple, and determine which commit should be applied according to the following rules:
« Ifcode blocks of VA and VB remain the same as the code block of Base, or both of them are changed in the same ‘way, inherit the code block from VA. In Figure 1, both VA and VB remove the definition of w (ie, deleting line 4 of Base). Due to identical modifications atthe same locations, Gt applies these changes. Ibis noteworthy that even for code removal, VA and VB maintain a pair of empty DCBs, symbolizing the deletion of lines.
‘* Ifonly one code block of ether VA or VBis changed, Git applies this code block, and mars this code block and the corresponding code block in the other variant as DCB. In Figure 1, VA alters lines 1-2 and introduces a new line at 3. Git's code-matching algorithm identifies these modifications, designating lines 1-3 of VA as DCB Zand lines 1-2 of ‘Bas DCB2. Since only DCB 1 changes, Git applies it to generate the code forthe Merged Commit at lines 1-3,
‘* Ifboth code blocks from VA and VBare changed, and the modifications are different, Git marks both code blocks as DCBs.As Gt cannot decide which one should be applied it emis a conflict containing the two DCBs. In Figure 1, VA and VB independently modify the definition of v7. Git detects these alterations, marking line 7 of VA as DCB Sand line 6 of VB as DCB 4. Since these two modifications der, Git cannot determine which one to apply. Consequently, Git signals the inconsistency between DCB 3 and DCB 4, prompting developers to resolve this conflict.
// int a= 1; int a = 1; ya [ant b= 25 int b = 25 Base int c = 1+ b; int c = 1+ b; printf(“%d", c); || printf (“%d”, c)5 int a = 1; // int a int b = 25 int b = 25 VB | int c= a+b: intc=a+b; |Mersed printf("%d", ¢); || print#(“%d”, c)5
Fig. 2. An example ofa clean but incorect Git mergewith the three-way merging algorithm
2.2 Limitations of Existing Approaches Despite being the most widely used code merging tool currently, Git merge faces the following two challenges: (Challenge
- cannot ascertain developers’ expectations fer code functionality: Consequently, when both versions modify the same code, Git treats this discrepancy as a conflict, necessitating manual intervention for resolution. We discussed how the conflicts are generated in §2.1 (Challenge 2)t cannct ensure the correctness of successfully applied and conflict free code blocks. Even when Git successfully merges two versions without conflicts, the merged code may be generated with new bugs, Figure 2 shows an incorrect merging scenario. Only the frst line of VA and the third lin of VB are changed, Manat abit to ACM.
Page 5
WizardMerge - Save Us Prom Merging Without Any Clues 5
Using Git merge, the two versions of code can be easily merged without any conflict (ie. the first line applied from. VA and the second line applied from VB). Unfortunately, in the merged version, the definition of variable ahhas been removed, which causes a compilation error atthe third lin. These DCBs enforced by Git without conflict, yet resulting, in unexpected results, are termed Violated DCBs. Given that these violated DCBs are not flagged as conflicts and are automatically incorporated by Git merge, they tend to introduce concealed programming errors into the merged code. In the most severe scenarios, these error-prone code segments might seemingly execute successfully but could potentially give rise to security issues post-deployment (22, 6]
(Over the years, researchers have concentrated on enhancing the quality of merged code and conflict resolution. However, these two basic limitations have not yet been filly resolved. On the one hand, structured (23, 35,44, 45] and sractured (4, 5,34] merging still report conflicts when the sume AST node is modified simultaneously by two ‘merging candidate branches. On the other hand, the conflict resolution assistance system [33, 44] and machine learning, approaches [3, 1-13, 15, 38, 43] only consider conflicts reported by the merge tool, ignoring all code snippets that have been applied, Additionally, automatic software merging tools [3-5, 11-13, 15, 23, 4, 35,38, 43-45] neglect an. soential observation: developers have unpredictable ultimate needs, therefore cannot filly overcome Challenge 1 ‘To better illustrate thie, we provide an example of implementing the Fibonacci sequence in Figure 3. Two versions, A and B, calculate the Fibonacci sequence using recursion and iteration, respectively. When attempting to merge these ‘versions, a conilict arises, and two developers resolve it. Although both developers decide to use the iterative approach from version B to avoid stack overflow for large values of n, they implement different strategies for handling negative values of. Developer A, inspired by version A, uses an unsigned definition for nto eliminate negative values (line 1 in resolution A), In contrast, Developer B opts to return zero when mis less than zero (line 3 in resolution B). Since developers’ decisions on conflict resolution are unpredictable, automatic software merging tools often fail ta produce
an acceptable resolution in such cases.
‘esionA Resolaion A Fine Fab(unsigned n) vetoes fine Fib(unsigned n) { if (ned) { Uataptenoa sch oven] Ant @ = 8, B= 1, Cb otety Unipefa ncaa ee a ree } else ( for (int {= 25 1 cen 44) Fetuon fib(n-1) + fib(n-2); cearbasd, bac } return b; a x oe y Nersion B Coniiet Resolution B jint fib(int n) { Jint fib(int n) { int a= 0, b= 1, int a= 0, b= 1, AF (n == 0) retutn 95 4F (nce 6) return for (Ant d= 25 4 <= 5 444) for (int 1 = 2; <= n; S44) edict aot) boc nf egdcty ao boc return bs atid ck oon] retUPn 5 b Koumtoo asec Ly
Fig.3. An example of different resolutions tothe same conflict
Furthermore, machine learning systems [3, 1-13, 15,38, 43] are limited in their ability to resolve conflicts in large codebases due to input and output sequence constraints. However, these conflicts typically do not significantly impact Manat abit to ACM.
Page 6
6 Qingyu Zhang, Junzhe Li, Jiayi Lin, Jie Ding, Lanteng Lin, and Cheniong Qian
developers’ time. For example, even MergeGen [13], the most advanced system available, filed to achieve satisfactory results when applied to the large-rcale targets evaluated in 4. Upon completing MergeGen's pre-training, we discovered that it produced no correct outputs, achieving an accuracy of 0%. Ths failure can be attributed to MergeGen’s default input and output sequence length limitations of 500 and 200 BPE, respectively [13]. These limitations are excessively stringent for large-scale project source code, leading to truncation of code beyond the prescribed lengths. However, the end ofthe truncated code is usualy far sway from where conflict oceurs and MergeGen cannot master the ability to resolve the conflicts given the trimmed training and testing cts, Attemptstorelaxthere length limitations areimpractical due to increased GPU memory consumption during training. Moreover, while machine learning techniques excel in generating merge results they may not abvaye align perfectly with developers’ expectations. Although MergeGen's cvalustion results demonstrate superior conllict cde matching precision and accuracy om a line of code basis compared to previous works [13] it stil falls short of espectations in some cases, with average precision and accuracy rates of| 71.83% and 69.936, respectively.
- Design Given the challenges outlined in the preceding section, we have identified two key insights. Addressing Challenge {we recognize that the expected outcomes of memges are subjective and open-ended. Consequently, our approach ‘emphasizes guiding developers in resolving conflicts rather than prescribing resolutions. To tackle Challenge 2, itis imperative to analyze all modified code. To this end, we present Wiza RDMERGE, a novel conflict resolution assistance system, which provides developers with clues and aids in conflict resolution. Moreover, WizanpMence emphasizes all ‘modified code snippets, not just conflicts, enabling it to uncover hidden discrepancies and preempt potential errors. A detailed design of WizanpMance will be presented in the subsequent subsections.
31 Overview
eeeers rc vee LJ omnis ee OF con
aes ont npn sort : sountenon) Las
Manat sated Fig. 4. system overview of WizanoMence
Page 7
WizardMerge - Save Us From Merging Without Any Clues 7
Figure 4 depicts the eystem overview of WizaRDMERGE. WizaRDMERGE first consumes compilation metadata from the two merge candidates through LLVM[Zs], WizaRbMEncr employs LLVM based on two insights: i) For large projects, code is compiled before a new version release to ensure compilation success, allowing WIZARDMERGE to collect metadata without introducing additional merging steps; ii) LLVM Intermediate Representation (I) provides 1 robust static analysis framework and comprehensive debug information, facilitating W1zaRDMERGE in performing definition dependency reasoning. To bridge LVM IR analysis with merge results from Git, the compilation metadata, also encompasses definition indicators. A definition indicator serves asthe representation of named definition section at the source code level, indicating the range and name of a definition. For example, a definition indicator of afunction records its Function name, along with its stat and end line numbers in the source code file. Subsequently, To identify ‘relationships between all modified codes, WizaRDMunGE advances to the Dependency Graph Generation stage. Instead of focusing only on conflicts, dependencies forall definitions are analyzed. WizaRDMERGE creates vertices for the definitions and establishes edges between vertices according to the dependency relationships of definitions analyzed. from LVM IRs. Following this, the Overall Dependency Graph (ODG) is generated to represent the dependencies ‘among all the definitions in both candidate versions of the target project. To attach its textual results with I-level dependency information, WizaRDMERGE aligns Git merge’s results and ODG to match DCBs with vertices in ODG. through Graph-Text Alignmont. This stage is capable of mapping DCBs to the corresponding definition nodes in each, ODG, refining definition nodes into DCB nodes, and transforming definition dependencies into DCB dependencies. ‘To rectify errors introduced by Git merge, WizanDMuncE employs an edge-sensitive algorithm in the Violated DCB Detection stage, detecting both conflict-related and conflict-unrclated violated DCBs. These violated DCBs and conflicts are categorized, prioritized based on the dependency graph, and presented as suggestions to developers to assist in
resolution, 42 Dependency Graph Generation
‘WizarpMunen first constructs ODG based on the LLVM IR and definition indicator, WizanpMunce currently supports the following types of nodes and edges
Graph node Subsequently, WizaRDMERGE generates nodes for each named definition with the corresponding indicator. Considering the types of definitions, WizaRDMERGE creates three types of nodes based on the indicator information: ‘Type Node (TN) represents composite types, eg, structure, class, type alias, and enumeration; Global Variable Node (GN) represents global variable; Function Node (FN) represents function.
Graph edge. Bach named definition may depend on other definitions within the project. For instance, a function, ‘might utilize a global variable or return a pointer with a specific structure type. Inthe ODG, these usage dependencies ‘among definitions are deduced from LLVM IRe and represented by the edges linking one node to another. The types of edges are defined by the types of their two connected nodes, An edge of type A‘B represents a dependency from node Ato node B. In WizannMuncr, five classifications of edges are supported: TN-TN, GN-IN, FN-TN, FN-GN and FN-EN,
[Note that WizaRnM nce will never generate an edge from TN to FN, even though member functions may be defined ‘within a composite type. Instead, WIZARDMERGE creates TN for all functions irespective of whether the function is standalone or nested within another scope. Fan FN represents a nested function defined inside a composite type, an N-IN edge is built to represent the dependency from the function tothe specific typ.
1m Generation
43 Resolving Suge:
In this stage, WizaRDMEnGE extracts DCB information from Git merge to aid in the analysis. Then, merging suggestions ‘can be generated based on the analysis results Manat abit to ACM.
Page 8
5 Qingyu Zhang, Junzhe Li, Jiayi Lin, Jie Ding, Lanteng Lin, and Cheniong Qian
43.1 Graph-Text Alignment. The merge results cannot be directly linked to the corresponding node in ODG. This is primarily because these results are raw texts that provide no additional clues for program analysis. In the raw reauls, a single large DCB may cover multiple nodes and a single node may encompass several DCBs. This N-to-N relationship complicates the analysis of the graph.
Before GaphTetAigament Afr Giaph Te Aignnent amare oT =a ana >| Start Lime: L1 + Start Lime: LS Sty eam) |e
Eade Se | | ERS
i mat ee Sino ‘Name: Named Def 2 Dep: (12.15) Bis =
SaetineLs Smee Code File with DCBs End Line: L7 ‘End Line: L7 Ein
Fig.5. Example alignment between node and OCB tet.
‘WrzarnMencr initially associates cach DCB with its corresponding definition indicators. To identify all nodes contained in the file where the DCB is situated, WizaRDMEnGE extracts the nodes whose range intersects with the DCB range. Ino matched node is found, it indicates that the DCB is notin a definition (eg, newlines or comments) and will not be further analyzed by WizanDMEncr. Treating each DCB as a ‘line segment’ its start and end line smumbers represent the coordinates ofthe line segment’s two endpoints on the coordinate axis. Similarly, each definition indicator of a node is considered as a unique "coloy’ The range ofeach node signifies a specific coordinate interval that is colored with the definition represented by the node. Thus, etreving the node during each DCB traversal can be seen as. color query forthe interval [start_Iine, end_Line], and interval modification and information maintenance can be cflicently managed using line segment trees. Fora target project containing N lines of code, each ‘coloring” and ‘eolor query" operation can be achieved with a ime complexity of O(logaN) [10]. WizanpMance subsequently logs all DCBs corresponding to each node, organizing them in ascending order of line numbers. The node is then subdivided into finer-grained nodes. The ranges of these finer-grained nodes are updated concurrently bared on the original node and ‘their corresponding unique DCBs. Fine-grained nodes belonging to the same definition will be connected sequential in range order, which implicitly expresses the dependency between code blacks. This mechanism ensures thateach node in ODG aligns with at most one DCB, effectively preventing any matching confusion within the ODG.
‘Taking Figure 5 as an instance, there are two definitions: Named Def 1, Named Def2. Before alignment, the nodes are created with their range information, Let's consider two DCBs associated with these definitions ([L2,L5] and [L6,L7)). To establish a one-to-one mapping between DCBs and nodes, each node can be divided into multiple ones, ‘while unaffected lines are excluded as they do not influence the merging. For DCB (L2,L5], WizannMuno detects that [22,13] belongs toNamed Def 1 and [L5,L5] belongs to Named Def?2. Consequently, a new node starting from L2 to L3 vwillreplace the original node for Named Def 1. As (L1,L1] remains unchanged it will be discarded. Furthermore, new node from L5 to LS is also formed since [L6,L7], representing another portion of Named Def?, corresponds to the DCB [6,17]. To indicate the code dependency from lines to previous lines within the same definition, an additional edge from node [L6,L.7] to node [15,15] is established.
‘As WizanpMunor ie tasked with managing two code versions (VA and VB), some nodes in the ODG of VA must ‘possess a corresponding mirror node in the ODG of VB. WizaRbMEnGE also constructs a mapping of each node to its Manat submit to ACM.
Page 9
WizardMerge - Save Us From Merging Without Any Clues 9
matched node in the other version's ODG by matching the name of the definition and the DCB metadata linked tothe node, Note that if one node is aligned with a DCB, it must have one unique mirror node with the other DCB in the same DCB pair Ifthe node has a matched node, the matched node must be the mirror node and the definition name is consistent with the current node. The matched node results contribute to the violated DCB detection via dependency ‘missing determination. Besides, the ODG's size can also be shrunk if there are nodes not attached to any DCBs, which ‘means they are not changed during merging, After the node deletion, the newly generated graph ie called Shrunk: Dependency Graph (SDG).
4.32 Violated DCB Detection. Violated DCBs are the underlying cause of seemingly successful but erroneous merging, ‘To offer developers a comprehensive understanding of the merging process, WIZARDMERGE detects violated DCBs based on an edge-sensitive algorithm and deems them as conflicts requiring resolution suggestions, Given the SDGs and node matching relationship, WIZaRDMERGE traverses each edge in the two versions of the SDG separately. Each, edge, starting from and ending at u, signifies that o relies on u. WizanbMuncz determines which version of the DCB associated with w and o is ultimately applied in the merge results (ce. fom VA, VB, or conflict). WIZARDMERGE then, ascertains whether these nodes represent violated DCBs by the applied versions and matching nodes of w and v. We introduce all the safe (ie. not violated DCBs detected) and violated scenarios as follows.
Symbols Definition. Let the SDGs from VA. and VB be represented at G4 = < V(Gq),E(Ga) > and Gp = < V(Gs),E(Gs) >, where V indicates the vertices set and E indicates the edges st For each vertex 0 € V, we represent its mimor node as Mi(e) and use metch(Mi(o)) to indicate whether the mirror node of isa matching node (True or False) belongs to only one ofthe Vy, Va, and Ve verter sets representing not applied, applied, and confit node sets respectively. For cach edge e(,u) € Zit represents an edge from to ,indzatng o's dependency on According to {he construction principles of SDG, there are two base facts:
Ifo eV, then Mi(o) €Vy, and vice versa.
Ifo € Vo, then Mi) €Vo.
‘Ascach 0¢ Va must indicate another verter (ie, Mi(e) belongs to Vig, WizanpManas only analyzes the cases where 9 €Vaor0€ Ve to avoid duplicate traversal.
Safe Scenaris. For each o and an edge: as safe
(0, u), we define the scenarios satisfying any ofthe following four formulas
ve Vawe Va ) 1 € Vau ¢ Va,match(Mi(u)) = True ) ve VoueVa )
0 Vou ¢ Va,match(Mi(u) In SDGs, the above formulas can be regarded as an edge-sensitive detection algorithm, which is visualized as depicted in Figure 6, For Equation 1, fboth w and o are applied, it means the dependency relation between nodes within the same SDG (as shown in Scenario 1 of Figure 6). By the same token, Scenario 3 alo illustrates such a direct dependency represented by Equation 3. For Equation 2 Scenario in Figure 6), 9 is applied but wis either not applied (u € Viz) or in confit status (u € Vc). Nevertheless, if the mirror of u matches w (match(Mi(u)) = True), it means that at least inthe other SDG, «can find its comesponding dependency applied (i, Mi(u)) although w is not applied, or both versions of conflicted hold the same dependency for v. To this end, WIZARDMERGE utes a virtual dependency edge from 0 to
Mansi abit to ACM.
rue C)
Page 10
10 Qingyu Zhang, Junzhe Li, Jiayi Lin, Jie Ding, Lanteng Lin, and Chensiong Qian
[Mi(u) to indicate a cross dependency between nodes from different SDGs. Similarly, Equation 4 (Seenario 4) is aleo
regarded as safe with the same reason.
u u Sxxmenil Semmng v u u Mi(u) Scenario 3 ycenario 6 v v
v oO Node from Vy oO Node from Vy CO Node from Vo
==» Maiching — Virtual Dependency Edge ——» Dependency Edge
Fig. 6. Edge traversal scenarios visualization
(0,1), all the scenarios not detected as safe arc regarded as violated,
Violated Scenarios. For cach 9 and an edge
scenarios, These scenarios are:
2 € Vasu ¢ Va.match(Mi(u)) = Falee 0 2 € Vo,u¢ Va.match(Mi(u)) = Falze ©
‘The Scenario and Scenario 6 in Figure 6 visualize Equation 5 and Equation 6 respectively. Once w ie not applied or in conflict, and the mirror node of u does not match it (match(Mi(u)) = False), it means that 0 misses dependency from w in both SDGs (when u € Vi), or Mi(u) holds a different dependency from u, which does not match 2's requirement (when w € Vo).
‘WizaxpMence identifies these cases are incorrectly handled by Git merge and marks the corresponding e, u, Mi(0) and Mi(u) as violated. Note that vertices with conflicts are always treated as violated, regardless of whether they are encountered in safe or violated scenarios. Finally, the DCB attached to these vertices are also marked as violated. Manat abit to ACM.
Page 11
WizardMerge - Save Us From Merging Without Any Clues n
YD Mirror,
MDG_Node_Di
MDG_Node_A
i) Not Applied Node!
_ Applied Node
— + MDG Edge = SDG Edge
Mirror MDG_Node_C
E+. Mirvor MDG_Node E~
Fig. 7. MDG example. Each node in MDG contains exactly a pair of mirror nodes in SDG. Each edge i built there fat least one SDG edge from one SDG nede to another.
- Priorty-Oriented Classification. WizaRDMERGE further minimizes the number of nodes that require processing and constructs a Minimum Dependency Graph (MDG) to emulate the dependencies ofthe merged version of ede. Inthe MDG, each node will consist of cither an applied node or a confict node and its matching node, and the edges between nodes will be created based on various SDGs accordingto the applying status. Specifically, while establishing the MDG, WizannMunce will traverse each conflict node or node associated with violated DCBs, and based on the applying status of the node, twill switch to the corresponding version of SDG and continue traversing the nodes in that particular SDG. Particularly, if the node isin conflict status, then the outcoming edges of both the mirror of| the node and itsef would be iterated. Concurrently, WizaRDMERGE sets up a directed edge between corresponding nodes for the MDG, relying on the encountered edges during traversal. Utimately, the MDG encapsulates the dependencies ofthe two versions of code to be merged.
Figure 7 shows an instance illustrating how MDG is built from SDG. Each MDG node is created from a pair of nodes related to conflict or violated DCBs. SDG node A-Eare from VA and all Mirar nodes are from VB. Starting from A and its mirror, WzanpMsRox iterates the outcoming edges and finds B is inked toa violated DCB. Then, Wiza RoMERGE creates a new node MDG_Node_B containing B and its mirror. As Bis not applied while its mirror node is applied, ‘WizannMncr iterates the outcoming edges of the mirror of B and finds a pair of conflict nodes (..,E and Mirror), which forms MDG Node_E. WizaRoMEncr then iterates the outcoming edges of both B and Mirror because of the conllct. By the same token, MDG_Node_D and MDG_Node_C are created.
‘WizampMencr then employs the Tarjan algorithm [39] to condense the MDG nodes and eliminate cycles. During this process, nodes in the same strongly connected component are regarded as having identical provty as these nodes nay reference each other within the code. In the case ofthe directed acyclic MDG, WizarnMrncr divides the MDG {nto muiiple subgraphs based on connectivity. All nodes within cach subgraph are grouped, and each node is assigned « prorty through the topological sorting of the subgraph, Nodes that appear later inthe topological orde signify that other nodes have greater dependencies on them, while the nodes themselves have fewer dependencies. Consequently, these nodes are assigned higher priority, enabling developers to address them earlier. In Figure 7, MDG_Node_
Manes bite ACM.
sential
Page 12
2 Qingyu Zhang, Junzhe Li, Jiayi Lin, Jie Ding, Lanteng Lin, and Cheniong Qian
[MDG.Node_D and MDG.Node_E are in the same cyclic of MDG and are thus assigned the same resolution priority as they depend on each other. After calculating the topological order, Wiz RDMERGE suggests that the DCB resolution priority should be (MDG Node_C, MDG_Node_D, MDG.Node, (MDG_Node_B}and {MDG_Node_A.
4 Evaluation In this section, we evaluate the effectiveness of W1zARDMERGE, aiming to answer the folowing research questions:
‘¢ RW: Can WizampMuncr help reduce the time consumption of merging conflicts?
‘¢ RQ2: Can WizampMuncr detect violated DCBs related to conflicts applied by Git?
4¢ RQS: Can WizanpMuncr detect violated DCBs unrelated to conflicts applied by Git?
Dataset Collection. We choose Firefox [29], Linux Kernel [30], MySQL [31], PHP [31], and LLVM [25] asthe target projects because oftheir widespread usage as open-source software. Additionally, they boast extensive code bases and sare maintained by multiple developers, resulting in repositories that feature intricate commits and merging scenarin. We collect 22 conflict pairs from Firefox, 43 from Linux Kemel, 17 from LLVM, 46 from PHP, and 99 from MySQL with 1 committing timeframe from 2021 to 2024. For each pair of conflicts, we only focus on the files in C/C++ format and guarantee they cither have at leat five conflict regions or violated DCBs detected. On average, a canfict contains 152433 lines of codes and i related to 6. files.
Evaluate with State-of the-art (SOTA) Systems. We initially intended to assess W124nDManct alongside other cutting edge systems. However, JDIME [1], Mastery [45], Spork: [23], SafeMerge [35], AutoMerge [44], InteliMerge [34] and ‘SoMany Conflicts [3] encountered language incompatibility issues within our datasets. Besides, migrating WIZARD- ‘Menor tothe languages these systems support is impractical because as an LLVM-based project, WIZARDMERGE requires ‘the fll support from the LLVM framework, while the compiler front ends of Java [37], Typescript [6], and Javascript [5] are till under development. Furthermore, FSTMerge[5] purports scalability contingent upon users implementing the merging engine for specific languages. Unfortunately its C/C++ parsers are either underdeveloped (ie, accommodating only basic syntax) or unimplemented, rendering it unsuitable for real-world projects In addition, as mentioned in §2.2, ‘the machine learning approaches [3, 11~13, 15,38, 43] meet the sequence length limitation challenge when facing the large-tcale targets we chose
Evaluation Environment. We evaluated WizanDMEnGE on an AMD EPYC 7713P server with 64/128 cores/threads, [NVIDIA Geforce RTX 4090 (24GB GPU memory), and 256GB memory, running Ubuntu 20.04 with kernel 54.0,
4.1. Effectiveness on Conflict Resolution, To adares (Git menge w/ and w/o WaanpMance) for merging conflict pairs. As WizanDMincr only provides suggestions instead of resolutions of conflicts, We have to assign two types of technical staff to the manual merging phase: skilled staffs, researchers with deep understanding of the project, and ordinary staffs, researchers having general understanding of| ‘the project. Initially, the ordinary staff employed WizaRDMERGE to analyze the two versions and performed the merge utilizing the suggestions provided by WizannManct, Subsequently the skilled staff manually merged the two candidate versions using Git merge without any additional assistance. We meticulously recorded the number of conflicts that can bbe analyzed by WHZARDMERGE and the time taken (with precision to the minute) from the commencement of conflict analysis to their complete resolution.
Manat abit to ACM.
RQ, we conducted a comparative analysis ofthe time consumption associated with two distinct approaches
Page 13
WizardMerge - Save Us From Merging Without Any Clues 13
Table 1. Conflict coverage of WaanoMence. Total Num indicates thetotal numberof conflict in each dataset. Analyzed Num indicates the numberof conflicts succesfully analyzed by WazanoMence. Cover Rate indicates the ratio ofthe above two columns
Dataset ‘Analyzed Num Total Num Cover Rate Fire 19 10 px imax Kernel ® es ss2%5 uve n n 966% Pa 26 2s onsen, MySQL pr a e26tm,
[Before comparing the effectiveness of merging w/ and w/o WIZARDMERGE, we first evaluate its ability to arse conflicts, As shown in Table 1, we calculated the total number of conflicts for each dataset and recorded how many conflicts can be successfully analyzed by WizaRDMERGE. WizaRDMERGE can give suggestions of more than 80% conflicts from the five targets. Notice that rome conflicts cannot be handled by WizARDMERGE, we manually dig the reasons Dbchind the failure. In the design section, we mentioned that WizaabMzncr's analysis is based on LVM IR. However,
in textual merging results, same conflicts are caused by the content of comments or preprocessing instructions (eg.
‘include and macro definition)-Since comments do not belong tothe code scope, and the preprocesting instructions will bbe expanded in the Clang front end, LLVMIR willlose the text information ofthese conflicts, and finally WizannMncn ‘will not give suggestions related to them.
TSLHO LS LMITSISHESIORSEFIESH Canc Par ID
Fig. 8. Manual merging time w/ and wo WeanoMesce.
“The effectiveness of menging w/ and w/o WizanpMencs is quantified by time consumption andie shown in Figure §. ‘When the time consumption of merging a pair of commits exccede 70 minutes, we will mark it as "> 70° and stop zesolving it In 135 out of 277 confit scenarios, WIZARDMENGE contributes to reducing version conflict resclution time, and asthe time consumption w/o WizaRDMERGE increases, the assistance ability of WizaRDMERGE also becomes more obvious. Remarkably, for the 208th conflict pair, manual merging w/o WIZARDMERGE costs more than 70 minutes, while ‘with the help of WiZaRDMEnGE, the merging process can be finished in 35 minutes. This exceptional performance is attributed tothe Priority. Oriented Classification module in W1zaRDMERGE, which provides categorization and fixes priority recommendations for manually resolved code blocks. Simultaneously, the Violated DCB Detection module
Manat abit to ACM.
Page 14
“4 Qingyu Zhang, Junzhe Li, Jiayi Lin, Jie Ding, Lanteng Lin, and Cheniong Qian
in WizanpMrncr automatically identifies code blocks related to conllicts. Ths feature simplifies developers’ efforts in analyzing dependencies and avoids the substantial time spent on the manual in-depth exploration of extensive code space required by Git merge. However, WizaRDMERGE may not optimize the time consumption for all data points. In 18 out of 277 conflict cases, using WizaRDMERGE could even increase the burden of conflict resolution. This occurs when only a small number of conflicts are present and few code blocks are affected, rendering WIZARDMERGE’s assistance not substantial Additionally, as mentioned above, WIZARDMERGE fails to generate suggestions on comments or preprocessing instructions
LUsting 1. Case study forconflit& violated DCB classification and WeeanoMence-produced resolving order assignment
Gite —git a/gt/Lnyors/serolbartata,h by gt/layere/erollbartate.h bygre/tayere/Scrolibaroata-b Sos areteInyere/seribaraata
- al. sSerolitracktngth, uintedt
- ° sBcrollbar.ayeriype(oerollbarLayarypa Thunb),
-
retera serolibaroata(abirection, sThabiatio, aThurhstert, athunbLeagth,
Manat abit to ACM.
Page 15
WizardMerge - Save Us From Merging Without Any Clues 15
Listing 1 presents a case study lustrating how WizaRDMERGE classifies the conflicts and violated DCBs and atsigns ‘resolving privileges between VA 145436 and VB 28194%e, Initially, both versions introduce distinct modifications to the ScrollberDataconstructor, resulting ina merge conflict (lines 817)Subsequently, both versions make different alterations to the parameter types of the CreateForThumb method in the SerollbarData class, leading to another merge conflict (lines 25-41). However, Git's strategy reports these conflicts directly to the developer without providing additional clues. In contrast, WizanDMEnGE utilizes dependency analysis between definitions to discern thatthe constructor of ScrollbarData willbe called by CreateForThumb (line 42). Consequently, WizaRDMERGE clasifies the two conflicts into ‘one group, assigning higher fx priority to lines 8-17 than to lines 25-41.
‘Additionally, VA and VB present diverse implementations of the function body of the CreateForThumb method. According tothe three-way merging algorithm, Git applied the code snippets from VB (lines 45-46) after detecting these toro conflicts, Moreover, within the pair of DCBs represented by lines 43-46 although lines 45-46 are applied without conflicts, it cannot ensure the constructor of SerollbarData receives the correct parameter types when both conflicts are present. This is because, ifthe developer chooses to apply all VA modifications when resolving these conflicts, the applied lines 45-46 from VB will ack essential parameters, aThumbMinL ength and aThumblsAsyncDraggabl, used by ScrollbarData constructor and the types of aThumbStart, aThumbLength, aScollTraekStart, and aScrllTrackLength will ‘not match the ScrollharDate constructor prototype. Nevertheless, WIZARDMERGE detects lines 45-46 and its mirror DCB (Ge, lines 43-44) through its innovative dependency analysis approach, treating them as violated DCBs. It reports them to developers along with other conflicts, Since lines 43-46 depend not only on ines 8-17 (function call) but also on lines 25.41 (definition of prototype), these two violated DCBs are grouped with the previous two conflicts, with fixed priority coming after the two conflicts, The resolution suggestions provided by WIZARDMERGE are shown in lines 49-58 of Listing 1, where items prefixed with C indicate pars of DCBs with conflicts, and items prefixed with A or B indicate DCB from VA or VB considered as violated DCBs,
Conchision: Our evaluation confirms WIARDMERGE can give suggestions for 72.45% of the conflicts. We analyze the time expenditures associated with conflict resolution and their corresponding DCB w/ and w/o the utilization of WizaRDMERGE to answering RQ1. On average, WizaIDMEnGE demonstrates a 23.85% reduction in resolution time. This underscores the efficiency and practicality of WizanDMEnGE in facilitating conflict resolution, even inthe context of large-scale real-world software.
- Violated DCB Detection ‘To address both RQ2 and RQ3, our initial step involves establishing the ground truth regarding the mumber of violated CBs by manually merging two code versions using Git merge. Subsequently, we employ WIZARDMERGE to conduct an analysis and document the identified violated DCBs, As not all code segments within a DCB pertain to violated.
Mansi abit to ACM.
Page 16
6 Qingyu Zhang, Junzhe Li, Jiayi Lin, Jie Ding, Lanteng Lin, and Cheniong Qian
Table. Violated DCB detection records. CR VA represents the LOC of CRviolsted DCB in VA, and CR VB represents the LaC of CR Violated DCB in VB. The format n/m indicates that there are m LoCs in total, of which WeeanpMence detects n. Similarly, CU VA, represents the LoC of CU violated DCB in VA and CUE represents the LoC of CU violated DCB in VB. The format n/m indicates that WeanoMence detect m LoCs ae CU violated DCB, ofwhich n are confirmed. Recall and Precision witht and+ stand for VA and VB respective
Dataset CRVA CRVB CUA CUVB Recall} Recall Precisiont Precision} Firefox ‘151/174 —«112/i23‘75/652 «9/717 _—«RSBOR LOOK ——«LLSOR «13.7% Linux Ker- 107/131 156/192 171/1245 108/905 S168% 125% «STIR 11.60% nel
LLVM aise 1623, N/A NA 67.00% © 957% = NA NA
PEP sais2 49/139 «226/324 213/358 69.70% 35K —69TSH —59.50% MySQL 12274/131003171/3469 1750/4597 1307/2427 93.60% LAI 38.07% SBR
DCB, we utilize Line of Code (LoC) for careful quantification ofthe violated DCBs. These violated DCBs are Further categorized into Conflict Related (CR) and Conflict-Unrelated (CU) violated DCB.
42.1 Conflict Related Violated DCBs. In addition to addressing conflict DCB, developers should reassess the DCBs automatically applied by Git merge. Resolving one conflict might potentially impact other sets of DCBs. Throughout cour evaluation, we recorded the LoC for DCBs linked to conflicts in both versions. This data reflects WizanDMEncE’s capability in elucidating the correlation between conflicts and violated DCBs.
‘Table 2 illustrates the CR-violated DCB detection results of WizaRDMaRGE. As VA and B's codes are different, the LoC of CR-violated DCBs in the same diff pair may vary as well. Thus, we documented the LoC from both VA and VB. According to the evaluation, 167 out of 227 conflict scenarios are confirmed to contain CR-violated DCBs. For most of the targets, WizaRDMEnGE successflly detected more than 60% CR-violated DCBs, providing a promising assistive cue for developers in ececuting manual fixes and facilitating them in exploring the CR-violated DCBs, Noticeably, although ‘MySQL datasets have the mort LaC of CR-violated DCBs, WiZaRDMERGE's detection recall even reaches 93.69%. For LLVM and PHP, WizanpMuncr showed moderate recall.
We alto delved inta the reasons behind WizaRpMEnGr's inability to detect CR-violated DCBs in certain datasets, Firstly, the Linux Kernel encountered compilation failure with the "00" option, a crucial setting for preserving debug information and preventing code optimization. Although "Og" can be used for better debug ability, itis akin to ‘OL? resulting in the elimination of significant debug information [14]. For instance, inlined functions are inserted at the invocation location and subsequently removed from the original code. As W12aRpMence depends on the collaboration of debug information and LLVM IR, the absence of debug information leads tothe failure of node generation and DCB ‘matching. Secondly, some datascts include violated dependencies among local variables within a specifi function or ‘macro definition, which Wiz 2pMunct’s analysis currently does not support.
Listing 2. Case study for conflict related violated DCBs
Manat submit to ACM.
Page 17
WizardMerge - Save Us From Merging Without Any Clues 7
= a1 aed yne
17,6 $145,000 tract sand.guawe ¢
Listing 2 presents an intriguing care study revealing conflct-elated violated DCBs detected by WHZARDMERGE between VA 5c5e0eS and VB lacfe2c. In VA, the definition for virine_r_dmais present, whereas atthe same position in VB, virtnet interrupt coalesce is defined. Git identifies these versions different modifications asa conflict and prompts ‘manual resolution for developers. Subsequently, Git designates other DCBs as notin conflict and applies them based oon their consistency with the base version's DCRs. Eventually, the code snippets from lines 24, 31, and 50-51 (from VA) along with 37-40 (Grom VB) are applied. Despite the differences between VA and VB in lines 46-51, lines 45-49 from VB are consistent with the base version's snippets. According tothe three-way merging strategy, it prefers to apply lines 50-51 from VA. In contrast, W1za2DMEnGr analyzes all modified code and discovers that even though the conflict is highlighted, some related DCBs have been applied without alerting the developers. For instance, applying lines 37-40 from VB assumes the presence of struct virtnet_nq_dma. Ye, ifthe developer opts for lines 15-17 as the conflict resolution, the structure becomes undefined within that context Similarly, applying lines 24,31, and 50-51 from VA assumes the definition of struct virinet_interrupt coalesce, while they will cause compilation errors ifthe developer
Manat abit to ACM.
Page 18
18 Qingyu Zhang, Junzhe Li, Jiayi Lin, Jie Ding, Lanteng Lin, and Cheniong Qian
Listing 3. The definitions of function EnsureNSS nitialized CChromeOrContat ate the same in both versions
sting 4. Diference between commits 42956504539 and 206204233 in flexpcomibaseinsCOMPtch
chooses lines 9-13 as the conflict resolution. Consequently, WIZARDMERGE identifies these code snippets as violated DCBsin conjunction with the conflict. Furthermore, WIZaRDMERGE assigns higher priority to the confit, signifying the dependency of other DCBs on the conflict and suggesting developers resolve the conflict before reconsidering these violated DCB.
422 Conflict-Unrelated Violated DCBs. Throughout this evaluation, we document the LoC for DCBs unrelated to conflicts in both variant versions reported by WizanDMence. Following this, we manually inspected the identified CBs and calculated the number of LoC genuinely violated among them.
‘The results of WizaRDMrnar's detection of CU-violated DCB are also presented in Table 2, As CU-viclated DCBs are isolated from conflicts, WizannM(ERGE demonstrates the capability to detect them, even in scenarios where it fails to hhandle any conflicts. In total, WizannMunGe detected CU-violated DCBs in 137 out of 227 conflict scenarios, while no (CU-violated DCBs were foundiin LVM. These DCBs, lacking necessary dependent definitions and automatically applied bby Git merge without developer notification, do not lead to conflicts but can result in compile errors or even latent bugs affecting users at runtime, While WizaRDMERGE show cas valuation also highlights instances of false positive CU-violated DCBs. This arises from the lack of function body analysis in WizanDMeRGE. According to WiZARDMEnGE’s DCB detection algorithm §33.2, the relationship between ‘two DCBs from the same function relies on line numbers, withthe later one forcibly dependent on the former one. If the two DCBs are applied from different versions, WIZARDMERGE marks them as CU-violated DCBs, even if they are ‘unrelated. This conservative algorithm may result in more false positives but WizaRDMEXCE prioritizes its application to prevent overlooking the detection of CUviolated DCBs.
Listing 3 and Listing 4 present another case study where WIZARDMERGE explores conflict-unelated violated DCBs ‘within Firefox (between versions VA {295656 and VB 2206204), which were overlooked by Git merge. Specifically, in the file nsNSSComponentcpp, both versions define the function EncureNSSInitializedChromeOrContent withthe samme contents, In Listing 3 lines 6-7, pointer to nalSupports is created via the template class nsCOMPr. The definition of, rnsCOMPtr is found in nsCOMPtrh, However, in addition tothe generic template, a template specialization [11] ie also defined for nsISupperts in VB, as shown in lines 11-15 in Listing 4. This specialization of nsCOMPrr for nsISupports allows users to employ nsCOMPirensSupports similarly to how they use nsISupprts” and void’, essentially as a ‘catch-all’ pointer pointing to any valid [XP]COM interface [0]. When attempting to merge nsCOMPtrh from the two versions Git applies the file from VA because the ile from VB is identical to the ile from the base version. Consequently, in the function EnsureNSSInitiaizedChromeOrContent, the usage of nsCOMPtrenslSupports> will fllow lines 4-7 in Manag submited to ACM.
its potential in uncovering violated dependency issues, the
Page 19
WizardMerge - Save Us From Merging Without Any Clues 1
Listing 4, causing nss to only be able to point to the single [XPJOOM-correct nsSupports instance within an object. This inconsistency can lead to a potential type confusion bug [19, 21]. Since no compilation error occurs after successfully being applied by Git merge, it would be extremely challenging for developers to notice such a bug, not to mention identify the root cause. With the assistance of WIzaRDMERGE, the loss of template specialization can be detected in the ‘merged version, thereby notifying developers to addr
it manually
Conchision: We astess the efficacy of WiZaRDMERGE in identifying CR-violated and CU-violated DCBs by ‘quantifying these DCBs in terms of Lines of Code (LoC), addressing both RQ2 and RQS. The results reveal that WIZARDMuRGE achieves a detection recall of 80.09% and 73.71% for CR-viclated DCBs from both merging candidates in the five target projects on average. Furthermore, despite attaining precision rates of 33.26% and. 34.66% for CUl-violated DCB in the four target projects on average, WIZARDMENGE effectively reveals deeply concealed CU-violated DCBs that are overlooked by developers. To underscore the impacts of CR-viclated and CU-violated DCBs, we present cate studies that further clucidate the rationale behind WizaRDMERGE’s noteworthy findings.
3 Discussion
Inthis section, we discuss the present limitations in WizaRDMEGE’s design and explore potential avenues for enhancing, WaarpMance.
[Improve Graph Generation. As discussed in §3.3, WIZARDMERGE incorporates three node types and five edge types to construct the ODG. While it adeptly manages mumerous merging scenarios, the evaluation outcomes highlighted in. {4 suggest that this incompleteness could result in an inability to address certain conilicts or violated DCB instances. For example, WizAnDMERGE cannot infer the dependency from a global variable to a function if the global variable is initialized by the function. This is because, during the compilation process, the initial values of global variables are established before the execution. In contrast, a function's return value is accessible only after being executed. ‘When initializing global variables with a function’s return value, the compiler transforms the function invocation into initialization code. To ensure the execution of this initialization code before the main program commences, the compiler positions this code within a specific section of the executable file, commonly denoted as the "init" segment. ‘This separation facilitates the execution ofthese initialization routines prior tothe initiation of the main program logic. We leave updating the features as our future work to adapt to such scenarios
Assess Code Optimization, WizanoMuEncE conducts dependency analysis based on the compilation metadata, Never: theless it overlooks a substantial amount of code information due to compilation optimizations like unused function. climination and vectorization [27]. As an interim measure, WizanDMEncx presently enforces the "OO" option. However, some projects require compilation optimization for successful building. Fr instance, the Linux kernel relies on opti- ‘ization to eliminate redundant code segments and disallows the "00" option. Inthe future, we aim to explore how to adapt our approach to arbitrary optimization options.
6 Related Work:
Structured Merging. Mastery [45] introduces an innovative structured merging algorithm that employs a dual approach: top-down and bottom-up traversal. It can minimize redundant computations and enable the elegant and. Mansi submited to ACM.
Page 20
20 Qingyu Zhang, Junzhe Li, Jiayi Lin, Jie Ding, Lanteng Lin, and Cheniong Qian
ficient handling of the code that has been relocated from its original postion to another location. Spork [23] extends ‘the merging algorithm from the 3DM [25] to maintain the well-structured code format and language-rpecific constructs ‘To fully retain the original functionality of the merged code, SafeMerge [35] leverages a verification algorithm for analyzing distinct edits independently and combining them to achieve a comprehensive demonstration of conflict freedom.
Semi-structured Merging. JDime [4] introduces a structured merge approach with auto-tuning that dynamically adjusts the merge process by switching between unstructured and structured merging based on the presence of conflicts PSTMerge [5] stands as an carly example of semi-structured merging, offering a framework for the development of semi-structured merging, Intelimerge [‘4] transforms source code into a program element graph via semantic analysis, matches vertices with similar semantics, merges matched vertices’ textual content, and ultimately translates ‘the resulting graph back into source cade files.
‘The above works, however, cannot help the developers with resolving conflicts. On the contrary, Wiza RDMERGE is constructed atop Git merge, furnishing developers with clues to aid manual resolution instead of dictating final merging decisions.
- Conflict Resolution
Confit Resolution Assistance. TIPMerge [2] evaluates the developers’ experience with the key files based on the ‘project and branch history [J] to determine the most suitable developers for merging tasks. Automerge [14] relies on version space algebra [25] to represent the program space and implement a ranking mechanism to identify resolution ‘within the program space that is highly likely to align with the developer's expectations. SoManyConflits [33] is implemented by modeling conflicts and their interrelations as a graph and employing classical graph algorithms to offer recommendations for resolving multiple conflicts more effcienty.
“Machine Learning Approaches, MergeBERT [3] reframes conflict resolution asa classification problem and leverages token-level three-way differencing and a transformer encoder model ta build a neural program merge framework, Gmerge [13] investigates the visbility of automated merge conflict resolution through k-shot learning utilizing pre- ‘rained large language models (LLMs), such as GPT-3 [16]. MergeGen [13] treats conflict resolution as a generation task, which can produce new codes that do not exis in input, and produce more flcible combinations.
‘The essential difference compared with existing assistance systems and machine learning approaches is that Wa- ‘ADMERGE considers all modified code snippets, which further helps developers resolv the violated DCBs in merging,
7 Conclusion
We introduce WIZARDMEnGE, a novel code-merging assistance system leveraging the merging results of Git and dependency analysis based on LLVM IR, named definition range, and debug information. Via the dependency analysis, WrzanpMencr is able to detect the lose of dependency of the named definitions, therefore providing more accurate merging order suggestions including conflicts and applied code blocks forthe developers. Our evaluation demonstrates ‘that WizaRnMunce significantly diminishes confict merging time costs. Beyond addressing conflicts, WizanDMERCE provides merging suggestions for most ofthe code blocks potentially affected by the conflicts. Moreover, WIZARD- ‘Mena exhibits the capability to identify conflic-unrelated code blocks which should require manual intervention yet automatically applied by Git.
Manat abit to ACM.
Page 21
WizardMerge - Save Us From Merging Without Any Clues a
References
[n} ala Aci, Palo Borba, nd Gaherme Cavan 2018 Undertunding semistructured merge confit characterises in opensource ora projets. Empirical Seffre Brinig 73 (018), 251-2085
[2] Mebhor Ahmed, Caius Brindesu, Unme Aya Manna, Cals Jensen and Anita Sarma 2017. An empires examination f the raticship eee code nme nd merge conic In 2017 ACM/IEEE International Sympaiam on Empirical Sofware Enpnering and Meomremert (ESE) IEEE, 5-7.
[5] Wad Aldndas, Na Meng and Francie Servant 2023, Automatic predctin of developer! resktion for software merge confi. jarnelof Sytem and Sftrare 206 (2029, 1136
[a] Sven Apel, lf Laenich, and Chustan Lega 2012, Structured merge wth auto-tuning blancng pein and performance In Procedings of the 20h IEEE/ACM intentional Confiene on AtomatedSoftvareEnineng 120-139.
[5] Sven Apel org Lib, Benjamin Brand Chistian Langues and Chitin Kistner 2011, Semistroctared merge retaking merge in revision conteel system. In rcedigs ofthe 1th ACM SIGSOFT eypaiu andthe Ith Eurepeon conference on Foundation of fare eincering,
[o) Apsara 2021 Ue LLM by JorScaptTypeSeript h/t pecaniuse ten oraseptypenspt 7, Assen 24Feh
[r] Attn 2022 it Mere. pe worl com/gttodalnuing-branches/g-merge, Ascend: 02-Oct
[s} Guthenme Corcan, Paulo Hor nd Pola Acco. 2017 Bralunting and improving semistructured merge. Prcedings of the ACM on ‘Progemming Languages 1, OOPSLA (201), 1-27.
[o] Caan Conta, Jai Fg, Leonardo Maras Anta Sarma, 2046, IPMarge: recommending expert fr ntegating changes om branches 1 Proceedings ofthe 206 2th ACM SIGSOFT ntertionl Symposium on Foundation of Sofware Enpnewing 5234
[to] CpAlgetios 202% Segment Tree tp/ep-algrtn.com/atastrctarsinegnent oti Accel: 20-08
[ut] Hlzabeth Dine, od My tow, Alem Seyatkorsiy, Christin Bird Mayu Nai, ar Shavers Lah 202, Deeper eing to merge progam IEE Tronatios on Software Eainering W, (212) 1599-16,
[t2] Jina Deng, Qiao Zhu, Zey Su, Ying Lou and Das Hho, a). Merge Cone Revelation: Clanton of Genertin? (4)
[3] Jina Dong. Quo Zhu, Zey Sn, ing ou and Dan Hao. 202 Merge Conf esto: Clasifation or Genera? 2133 TEEEACM nterntionl Conference on atomatd Software Erginerng (ASE) TEE 1652-168,
[14] Changin Da. 2018, kernel hacking: CC opinion for beter chug experience (Op) tpn Aside 75369. Accel: 24 Jan,
[tS] Pat lag, Heleno de Campo eiog Edoardo Opumoras sd Leonard Gest Paling Mura 23, Toward acute evommensatins of ‘merge conflicts resin arategien Infrmaton nd Softer Teale (23,1075
[16] tains Foi and Manin Chae 200. GPT: utr, scopes and commence. Mindsand Machine 30 (2020, 61-184
[a7] Gi. 200. peso cm. Accemed 2023-0
[ts] ie 2003 Ge Merge. z:gi-sm condone merge Accent 223-02.
[19] tan Haller, Yasok Jon, Hui Peg, Mathias ayer Ceitiana Gili, Herbert Bo, and rie van der Kou. 2016 Types: Pract Type (Confusion Detection In Proceedings of the 2016 ACM SGSAC Confrence on Computer and Communications Sart Vienna, Aarts) (CCS 8 Azsciton for Computing Machinery, New Yat, NY, USA, 517-528. Ip:/oiog 041452976740 3978105
[20] Kaman Handy 203. The Bigg Coden in History, ae Meare by Line f Cade parr astetatincom bogs Sey Rothe igget-codeane--hitary-armeurel-by Hiner of cole, Acree: 02 Jon,
[at] ase Jeon Priam Biswas Sot Car Byoungyonng Lee, and Mathie Pax 2017 Hedy: fit Detection of Type Confusion ree far (Cs a Procednr ofthe 2017 ACM SGSAC Confrence on Computer and Conmaniton Sear ty (Dalla, Texas, USA) (CCS 7} Ascii for Computing Machinery, New Yor NY, USA, 2972-2807. ipaoion/10S14/920056215082
(22) Jin Kana 2014 GIT merge ccs bat nrodce comptioneror te ackoveln com quo 770g merge-mcentl~ ut ntodicevconplation enor Acne: 32a
(23) Sion Laan Jan Remy Fler, Beast Bandy, and Martin Monperu. 202. pk Stretred Mere fr Java with Formating Preservation IEE “ramcion on Sofware Engine 8,1 (2022, 6483.
[24] CheisLatner 208, LLYM and Clang-Next generation cpr techno In The BSD cofrnc Ve 51-20
[a5] Term Ln, Steven AWelfian, deo Domingos and Daniel S Weld 208 Programming by demonstration using vein pace serra, Mac ering 53 (09), 11-156
(26) anced Lndhokm, 2004. thee-way mene for XML documents Ia Poeeings of he 2004 ACM sympa on Dosenteginerng 10
[27] LOM, 2008 LLVM'sAnabse and Traafm Passes tp /lvmordocs/Psn bl, Aces 3D
[es] LIVM, 2026 The LLVM Compiler Infrae ite/lvmor. Accel 027:
[op] Moni 2024 Mewar Gecko Repost tp:/emexila og Ace: 23-Dec
[0] Mona 2024 GeckosdersauCOMPtch. te/gthshcon/mailagecko-de oy a20<204735%4E afc both 2Abaepomse! snsCOMiNch Accel 202601-25,
[st] Myst 2024 MySQL bupe/der mye. Acceed 2004p
[st] YeihiNikimer and Katrin Maruyama. 2016. Supporting merge confit resation by wing ne rained code change hier In 20 IEEE 2rd Inerntianl Confience on Sftre Anal, Elution, and Reining (ANER} Vo 1. IEEE, 66-64
Manat abit to ACM.
Page 22
2 Qingyu Zhang, Junzhe Li, Jiayi Lin, Jie Ding, Lanteng Lin, and Chensiong Qian
[83] Bo Shen, Wei Zhang, Aun Yu, ian Shi, Hayan Zhao and Zhi fn. 2001 SaManyConficts: Reve many merge colts interactively and systematic I 2021 3th IEEE/ACM beratinal Confrnet on Automated Seftrare Bini (ASE) IEE, 1291-1295
[24] Bo Shen, Wet Zhan, Huiyan Zio, Guangtai Ling, Zhi, and Quaeiang Wang 2019 IntliMerge:arutoring-aware oftware merging technique Frcedagrofthe ACM on rgramming Languazes3, OOPSLA (219), 1-2
(25) Marcel Sou, il Dili, nd havendsK ahi 2018 Ved tee say progam merge. Prcenings of he ACM on Programming Longuager2, OOPSLA (2018), 1-28
[36] Calvin Spelman. 2018, When a Clean Merge i Wrong, tp cturoup cmap 2018) 1when- lean merge-wrone. Acceed 2b
[a7] Alexey Sepacy 2020, What'sthe dilfeencebebveenKoiyNativ nd Jv bytecode ith compl ough LLVM feted? btp:tacovedone ‘cen/quetons/ 8801 85\what the difeeace beter natveant joa-ytecode-with-ompie thas, Acreaeak eh,
(a8) Alexey Sryathkiy, Sarah Flory, NegarGhoran, Todd Myowi, Elizabeth Dinlla, Christan Bird, Jn Jang, Nel Sundaern nd ‘Stover K Lak 2022, rogram merge conflict ocation via neural tranfomers In rowed ofthe Se ACM Jot Earp Sofvare Entineing Confrcne and Symp onthe Foundation of Softarenginarng 22-13.
(a0] Robert jan 197. Depbfst search and liner graph algorithms. SAM journal on computing 121972) 86-16,
{ao} Linas Twas 2028 Lin Keel Oeil Repository. hps:gihubcomforaliins. Accented 223-0
[at] David Vandevoorde ad Nicola M Jontie. 02 Cr+ templates The comple id prtaie dimers Adnan Wey Pelco
(la) Aese Mii Viner 2023. The Mage of Way Merge tpg int omthe magic way merge Accel: 2022-0
[es Jide Zhang, Todd Mythowic, Mike Kaufnao, Ria Pac ad ShvendaK Labi 202, Using poe-trined lngunge modelo rake textual spd semanic merge conics (experince pape) In Proceeding ofthe at ACM SGSCET International Symposium on Sofware Teng end Anabeic
[at] Fengmin Zhu and Fei He. 2018. Cont ealton Fr structured merge via version spce agen. Prcedings ofthe ACM on Programing Language 2, OOPSLA (2018), 1-25.
[45] engin Zh XingyoXix,Dongy Feng, Na Meng and el He. 202. Matery Sie Coe wareStracured Merging In Itai Spar on Dependale uf Bngnewng: There, Tl and Aplications Springs 70-87.
Manat abit to ACM.