PaperlayerView exact revision on arXiv

Source-linked AI summary

An Empirical Study on the Impact of Change Granularity in Refactoring Detection

Lei Chen, Shinpei Hayashi

arXiv:2609.07482v1cs.SE

TL;DR

Single-commit detection can miss refactorings whose changes span multiple commits or whose integrity disappears in broader history. The study defines and detects coarse-grained and ephemeral refactorings, finding that coarse-grained refactorings are common and that detection may be affected by git-blame inaccuracies.

  • Problem

    Single-commit refactoring detection is insufficient for refactorings recorded across multiple commits or disrupted by adjacent changes.

  • Method

    The study defines coarse-grained and ephemeral refactorings and compares refactorings across commit granularities using descriptions, types, and location information.

  • Results

    5.71% of refactorings are additionally identified as coarse-grained refactorings when examining changes through granularity level 5; 76.4% of sampled CGRs are Generation type.

  • Takeaways & Limitations

    Coarse-grained refactoring detection should not be overlooked because these refactorings occur commonly and may be indicated by commit messages.

  • Takeaways & Limitations

    Git-blame inaccuracies may affect the correctness of CGR/EPR detection.

Abstract

from arXiv · show

Detecting refactorings in commit history is essential to improve comprehension to code changes on code reviews, and to provide valuable information for empirical studies on software evolution. Techniques have been proposed to accurately detect refactorings on the granularity of a single commit. However, refactorings can be made over multiple commits because of their complexity or other practical development problems, which cause detecting on only the granularity of a single commit not enough. We observe that some refactorings can only be detected in coarser granularity, i.e., changes conducted over multiple commits, or in the granularity of a single commit but not in coarse-grained. We call these types of refactorings as coarse-grained refactorings (CGRs) and ephemeral refactorings (EPRs). We investigated the features and causes of CGRs and EPRs through an empirical study of 32 open-source Java projects and found that both commonly occur during development. In addition, we found that refactoring types related to splitting or merging classes and packages, as well as those involving modifications to the inheritance structure, tend to be CGRs, and types targeting small objects such as variables and attributes, and refactorings with context-sensitive detection criteria tend to be EPRs. The causes of CGRs and EPRs are analyzed and categorized, and the relationships between the commit messages of CGRs and themselves are also assessed. We found that about 20% of commit messages explicitly suggest the existence of CGRs. We suggest that CGRs and EPRs be valued in refactoring research and that detectors be extended to identify CGRs.

1. Introduction

Single-commit refactoring detection can miss refactorings distributed across commits or obscured by broader changes. The paper defines CGRs and EPRs, studies them in 32 open-source Java repositories, and reports their prevalence, characteristics, causes, and relation to commit messages.

  • Motivation: Commit-level detectors can miss refactorings whose changes span multiple commits, motivating analysis at coarser granularities.A Move Method may become detectable only after its implementation is copied and then removed across separate commits.
  • Definitions: CGRs span multiple commits, whereas EPRs are detectable within one commit but disappear when adjacent commits are included.The paper uses these categories to characterize refactorings whose detectability depends on historical scope.
  • Study scope: The study analyzes CGRs and EPRs through an empirical investigation of 32 open-source Java repositories.It examines their features, causes, developer intentions expressed in commit messages, and implications for researchers and practitioners.
  • Findings: 5.71 CGRs and 9.89 EPRs occur on average per 100 refactorings conducted.The findings characterize both categories as common during development.
  • Findings: Splitting or merging classes and packages and modifying inheritance structures tend to produce CGRs, while operations on variables, attributes, and parameters tend to produce EPRs.The paper also identifies Generation and Combination as CGR causes, and Disruption, Absorption, and Covered as EPR causes.
  • Findings: 20% of commit messages explicitly express the existence of CGRs.The messages are categorized into four types, supporting analysis of developers’ intentions around multi-commit refactorings.

2. Coarse-Grained and Ephemeral Refactorings

CGRs and EPRs classify refactorings by how their detectability changes across commit granularities. The paper illustrates both concepts and places them within existing commit- and release-level detection research.

  • Coarse-Grained Refactoring: A CGR records its code changes across multiple commits rather than within a single commit.In mbassador, copying and removing class implementations across two commits jointly realizes a Move Class refactoring.
  • Ephemeral Refactoring: An EPR is recorded in one commit but becomes undetectable when changes in adjacent commits are included.In RoboBinding, Extract Variable and Inline Variable refactorings detected separately are not detected across the combined two-commit change.
  • Terminology: The paper’s CGR and EPR concepts concern how refactorings are recorded across commits in version control, unlike other uses of the term coarse-grained refactoring.This distinction separates the paper’s commit-history focus from concepts based on target size or low-level transformations.
  • Research gap: Existing detectors commonly compare source snapshots at release or individual-commit granularity, leaving an intermediate multi-commit level underexplored.The paper identifies refactorings applied across multiple commits as an unresolved gap in current detection studies.

4. Detecting Coarse-Grained and Ephemeral Refactorings

The detection approach changes repository granularity, runs a refactoring detector at fine and coarse levels, and matches results using refactoring signatures that account for traced locations. This comparison identifies CGRs and EPRs while addressing location shifts caused by squashing commits.

  • Detection mechanism: The approach squashes fine-grained commits into coarse-grained commits, applies RefactoringMiner to both, and compares the resulting detections.The basic mechanism contrasts refactorings found in original commits with those found after combining commits.
  • Classification: Refactorings detected only in coarse-grained commits are CGRs, while those detected only in fine-grained commits are EPRs.Refactorings matched across both granularities are classified as neither category.
  • Matching scheme: Refactoring signatures combine type, description, and target location, with file paths and line numbers helping distinguish otherwise similar instances.Location information is especially useful when same-type refactorings or similarly named elements occur together.
  • Matching scheme: Changing granularity can shift line numbers, so exact location equivalence is insufficient for matching corresponding refactorings.Inserted code can move a Rename Method target from one line in a fine-grained commit to another line in a squashed commit.
  • Matching scheme: The method traces refactoring targets to their origin commits and lines, and the enhanced signature uses traced location together with refactoring type.The revised scheme is intended to uncover more CGRs and EPRs with higher accuracy than matching by type alone.

5. Methodology

The study transforms fine-grained commit histories into coarse-grained histories, detects refactorings at both levels, and matches results while tracing changed locations. It compares detections across granularities to identify CGRs and EPRs.

  • Study procedure: The procedure has repository transformation and detection-and-match phases.Preprocessing removes Javadocs and comments, and consecutive same-branch commits are organized into squash units before matching detections.
  • Repository transformation: Straight commit sequences exclude merge commits and branch sources before squash units are formed from adjacent fine-grained commits.This avoids duplicate detection and simplifies the transformation.
  • Repository transformation: Granularity level ℓ determines squash-unit size, while offset o enumerates alternative groupings of commits.ℓ=1 reproduces original fine-grained commits; different offsets cover possible squash units at each higher level.
  • Repository transformation: The transformed repositories are generated by squashing multiple commits into one coarse-grained commit using git-stein.The relationship between original commits and transformed commits is retained through squash-unit associations.
  • Detection and matching: RefactoringMiner detects refactorings in fine- and coarse-grained histories, which are matched using type, target signature, and traced location.The primary target is the first element in the pre-refactoring code snippet; git-blame supports tracing locations altered by granularity changes.
  • Detection and matching: CGRs are obtained by comparing coarse-grained detections with detections at lower granularities, using improved signatures and excluding refactorings already found at finer levels.This refines earlier type-only matching and improves conceptual validity.

6. Empirical Study

The empirical study examines how often CGRs and EPRs occur, which refactoring types exhibit them, how they arise, and how commit messages relate to CGRs. It evaluates the approach on 32 Java repositories and assesses detection precision and efficiency under granularity changes.

  • Research questions: Five research questions address CGR and EPR frequency, types, causes, commit-message evidence, and EPR features.The questions cover appearance frequency, type analysis, development causes, message relationships, and EPR characteristics.
  • Dataset: The dataset contains 32 GitHub-hosted Java repositories selected from a 124-project dataset containing researcher-confirmed refactorings.Selection sought to mitigate bias from differing coding conventions and application domains.
  • Precision: The preliminary precision review found 2 false positives among 55 CGRs, yielding 96.36% precision.This was slightly below the tool authors’ reported 99.6% precision and was considered acceptable given the increased complexity of squashed commits.
  • Efficiency: Granularity changes produced a statistically significant positive correlation with average RefactoringMiner detection time.Squashed commits contain more code elements for the detector to analyze, increasing average detection time.
  • Overall evaluation: The study concludes that granularity affects RefactoringMiner’s precision and efficiency, but the impact remains within an acceptable range.This conclusion summarizes the preliminary evaluation under granularity changes.

1: How frequently do CGRs appear because of granularity change?

CGRs occur across repositories, but their frequency declines as the granularity level increases. Across all repositories, cumulative CGR frequency reaches 0.0571 at level 5, while commit volume is positively correlated with detected CGRs.

  • CGRs appear in all repositories, with positive relative amounts across nearly every granularity level.Only three repositories have zero frequency at particular levels.
  • Pearson’s r = 0.748 with p < 0.001 links commit volume in straight sequences to the number of detected CGRs.Repositories with similar commit counts can still show notably different CGR counts.
  • CGR frequency decreases as granularity increases, because classification at coarser levels requires one refactoring’s changes to span all consecutive commits in a larger squash unit.
  • 0.0571 is the accumulated CGR frequency at granularity level 5, corresponding to approximately 5.71 CGRs per 100 refactorings.The cumulative frequency rises with granularity but increasingly saturates.
  • The most frequent CGRs occur at granularity level 2, and the study reports an additional 5.71% CGR frequency when considering granularity up to level 5.

2: What are the types of CGRs?

CGRs comprise 98 distinct refactoring types, with rankings varying by granularity. Splitting or merging packages and classes, along with inheritance-related changes, are especially associated with CGRs because they commonly span multiple commits.

  • 98 distinct CGR types were detected, and their rankings vary across granularity levels.
  • 29.63% is the appearance ratio of Split Package, the most frequent CGR type at granularity levels 2 and 3.
  • 23.44% and 18.00% are the appearance ratios of Split Class and Merge Class, the most frequent types at levels 4 and 5, respectively.
  • Except for Replace Attribute, the top three CGR types are associated with splitting or merging packages or classes.
  • The study illustrates CGRs through Merge Class, Split Package, and Replace Attribute examples spanning two or three commits.
  • CGR types involving package or class splitting and merging, plus inheritance-structure modifications, rank highly because they are complex and often implemented incrementally.These changes commonly affect multiple parts of the codebase and span several commits.

3: How are CGRs introduced in development?

CGRs were analyzed through manual review of 110 sampled cases, which were classified by how their component changes compose. Most were generated from non-refactoring changes, while the remainder combined multiple refactorings.

  • 76.4% of sampled CGRs were Generation type, while 23.6% were Combination type.Generation arises from fine-grained non-refactoring changes; Combination combines multiple refactoring changes.
  • Generation: Generation CGRs emerge when non-refactoring changes collectively produce a detectable refactoring across commits.Examples include copying an implementation and removing the original class, or changing related attribute and method-call code across commits.
  • Combination: Combination CGRs result from multiple refactorings detected in finer-grained commits and combined at coarse granularity.The paper illustrates this with package splitting, package merging, and class moves across commits.
  • Classification: The authors conservatively classify borderline cases as Combination when any compositional aspect is present.This policy acknowledges that a component may otherwise resemble a Generation case.
  • Implications: Generation and Combination CGRs can affect judgments about whether modules were refactored and the observed frequencies of refactoring types.The paper suggests that tools recognizing manual edits and studies covering coarse-grained types can address these implications.

4: Do commit messages suggest the existence of CGRs?

The study found that commit messages can explicitly or indirectly signal CGRs. In the examined sample, 20% of CGC messages explicitly suggested CGR existence, with recurring patterns involving split work, unfinished refactoring, related commits, and connected changes.

  • Message characteristics: Same-content messages appeared in 8/110 CGCs and often indicated that one refactoring had been split across multiple commits.The paper links this pattern to developers dividing complicated refactorings into steps to reduce user-impact risk.
  • Message characteristics: Messages explicitly stating that refactoring was unfinished appeared in 2/110 CGCs and signaled continuation across commits.In one example, a later commit completed a class move begun by an earlier incomplete change.
  • Message characteristics: Connections among consecutive commits can signal CGRs even when their relationship is not explicit in the messages.Such connections may involve changes to the same or related modules, although recognizing them requires code and repository knowledge.
  • 20% (22/110) of CGC commit messages explicitly suggested the existence of CGRs.These messages were categorized into four characteristics, with same-content messages being the most frequent.

5: What are the features of EPRs?

The study examined EPR characteristics through three sub-questions, aiming to understand their features beyond their definition as refactorings sensitive to detection granularity.

  • The EPR analysis explored their characteristics through three sub-questions.The supplied passage identifies the analytical structure but does not state the three sub-questions.

5a: How frequently do EPRs appear across the studied repositories?

EPRs occurred across all 32 studied repositories and were most frequent at granularity level 2. Their median frequency declined as granularity increased from levels 2 through 5.

  • The median EPR frequencies at granularity levels 2, 3, 4, and 5 were 0.0490, 0.0273, 0.0141, and 0.0108, respectively.Figure 17 presents these distributions using boxplots of frequency and accumulated frequency.
  • EPRs were detected in all repositories, indicating that EPR is a common phenomenon.The study examined 32 repositories.
  • EPRs appeared most frequently at granularity level 2.This conclusion is stated across the studied repositories.

5b: What are the most common types of EPRs?

EPRs most often involve small code objects or refactorings whose detection depends on context-sensitive criteria. These patterns reflect how modifications accumulate or are disrupted across commits.

  • Small-object operations, including variables, attributes, and parameters, dominate the top EPR types across granularities.Rename Package also targets a small object because it changes a name string.
  • The highest appearance ratios are Modify Parameter Annotation, Merge Method, Remove Parameter Modifier, and Split Variable at granularity levels 2 through 5, respectively.
  • Small objects tend to produce EPRs because they are continuously modified across multiple consecutive commits.
  • Merge Method, Split Class, and Split Package frequently become EPRs because their context-sensitive detection criteria are easily disrupted during squashing.

5c: How are EPRs typically introduced in the development process?

EPRs arise when refactoring evidence is disrupted, absorbed, or reverted as development changes are combined across commits. In a manual review, disruption was the dominant cause, while reverts were often visible in commit messages.

  • EPR causes were categorized as Disruption, Absorption, and Revert.
  • Disruption occurs when a non-refactoring change violates a refactoring detector’s match condition, preventing identification after commits are squashed.
  • Absorption occurs when multiple refactorings affect the same object and some become undetectable within the overall coarse-grained process.
  • Revert EPRs arise when a refactoring is introduced in one commit and reversed in a later commit.
  • 74% (38/50) of reviewed EPRs were Disruption, 18% (9/50) were Absorption, and 6% (3/50) were Revert.
  • Two of three Revert-type EPRs were explicitly mentioned in commit messages.

8. Implications for Researchers and Practitioners

The findings suggest that refactoring tools and empirical analyses should account for refactorings spanning different commit granularities. Developers and reviewers can also use CGR and EPR awareness to improve traceability and reviewability.

  • Implications for Researchers and Practitioners: Refactoring detectors should support single-commit, multi-commit, and version-level granularities to capture refactoring activities more accurately.
  • Implications for Researchers and Practitioners: IDE and CI integration can reveal grouped changes representing higher-level design intent and reverted changes that may be misoperations.
  • Implications for Researchers and Practitioners: Tools can recommend multi-step refactorings by learning frequent CGR types and aligning recommendations with developer workflows.
  • Implications for Researchers and Practitioners: CGRs and EPRs expose a gap between how changes are recorded and the granularity at which refactorings are actually conducted.
  • Implications for Researchers and Practitioners: Explicitly annotating CGRs and EPRs in commit messages can improve clarity and traceability during code review and inspection.
  • Implications for Researchers and Practitioners: Awareness of CGRs and EPRs helps reviewers understand both fragmented changes and the broader software evolution path.
  • Implications for Researchers and Practitioners: The study investigated commit-granularity effects using 32 open-source Git-based Java repositories and identified CGRs and EPRs as special refactoring types.
  • Implications for Researchers and Practitioners: Future work includes studying how commit integration paths affect CGR and EPR occurrence and how developers perceive these refactorings.
Loading 2609.07482v1…