Pith. sign in

REVIEW 3 major objections 3 minor 1 cited by

Refactoring-Aware Patch Integration Across Structurally Divergent Java Forks

T0 review · 3 major / 3 minor · reviewed 2026-08-05 · deepseek-v4-flash

Challenge this review Re-run · record.json Download PDF Read on arXiv ↗ Review JSON

Pith's one-line read RePatch recovers over half of the bug-fix patches that Git cherry-pick cannot apply across structurally divergent Java forks.

desk verdict A credible, useful tool paper on refactoring-aware patch propagation across forks, with a real empirical contribution and an honest caveat that 'success' is measured by conflict-free application, not by passing tests. read the letter →

arxiv 2508.06718 v1 pith:IL5Y5YAV submitted 2025-08-08 cs.SE

Daniel Ogenrwot , John Businge This is my paper · ORCID
classification cs.SE
keywords patchintegrationrefactoring-awaremerginginvert-and-replaysoftwarevariantsstructuraldivergencecherry-pickfailureJavaforksbug-fixpropagation
verification ladder T0 review T1 audit T2 compute T3 formal

The pith

A machine-rendered reading of the paper's core claim, the machinery that carries it, and where it could break.

The reading

Long-lived forks of the same Java project drift apart—methods get renamed, classes move, code is reorganized—so a bug fix merged on one side often will not apply to the other using Git's standard cherry-pick. The paper's central claim is that this failure is mostly caused by refactorings in the receiving variant, and that undoing those refactorings on both sides, applying the patch, and replaying the original structure recovers a majority of the lost fixes. On 478 bug-fix pull requests across 14 divergent fork pairs, the authors report a 64.4% cherry-pick failure rate and a 52.8% recovery rate with their system RePatch, with fewer than 4% of integrations introducing new conflicts. If correct, this makes bug-fix propagation across independently evolving forks a tractable, interpretable automation task rather than a manual reimplementation chore.

What carries the argument

The central mechanism is 'invert and replay.' RefactoringMiner identifies behavior-preserving structural transformations (renames, moves, inlining) in both variants; RePatch inverts them to realign the patch context, applies the bug-fix commit, and replays the inversions to restore the target variant's structure. This extends RefMerge's symmetric operation-based merging to asymmetric, patch-scoped integration, and it is what turns structural drift from a blocker into a navigable mapping.

What would settle it

Take 50 of the 478 pull requests that RePatch integrated, apply them to the target variant, then compile and run the target's test suite; if a meaningful share fail to compile or fail tests that the manually ported fix passes, the 52.8% recovery rate overstates behavioral success.

Watch

Extended reading notes

Core claim

On the paper's own terms, the discovery is that asymmetric patch transfer can be modeled as refactoring inversion plus replay. Where Git cherry-pick aligns text, RePatch aligns structure: it detects refactorings in both the source merge commit and the target head, inverts them to bring the patch context into correspondence, applies the patch, and replays the target's transformations so the variant keeps its own structural intent. Using this mechanism on 478 bug-fix pull requests from the PaReco dataset across 14 Java variant pairs, the paper reports that 91.6% of cherry-pick failures are traced to target-side refactorings, and RePatch successfully integrates 52.8% of previously failing patch

Load-bearing premise

The claim that RePatch 'successfully integrates' a patch rests on applying it without syntactic conflicts; the paper did not run test suites or otherwise validate that the integrated patch preserves the fix's behavior in the target variant.

Editorial extensions

If this is right

  • Bug fixes that currently wait months for manual porting could be propagated automatically in more than half of the cases where textual cherry-pick fails.
  • Teams maintaining variant families can get interpretable diagnostics: each failure is explained by the refactoring that caused it, not by a black-box prediction.
  • Refactoring-aware replay can be used before manual resolution, since it introduces new conflicts in fewer than 4% of attempts.
  • The mechanism supplies a semantic layer on top of Git, so standard workflows (cherry-pick first, RePatch second) can be adopted incrementally.

Reading between the lines

Editorial extensions of the paper, not claims the author makes directly.

  • Behavioral validation is the open test: running target test suites on RePatch's recovered patches would tell whether 'integrates' means 'applies' or 'works'.
  • The explicit refactoring logs could be fed to LLM-based porters for the roughly 47% that still fail, giving those models a structural map instead of raw tokens.
  • A multi-hop variant network could use the same invert-and-replay step pairwise, propagating a fix through intermediate forks rather than only direct source-target pairs.
  • Adaptive timeouts and parser-agnostic refactoring detection would likely move some of the 17 timeout failures into the success set.
Share X Bluesky LinkedIn Reddit HN

Signed reviews

No signed human review yet.

Editorial analysis

A structured set of objections, weighed in public.

Desk editor's note, referee report, and a circularity audit.

Referee Report

3 major / 3 minor

Summary. The paper studies patch integration across long-lived Java forks ('variants') that have evolved independently. Using 478 bug-fix pull requests from 14 variant pairs, it reports that Git cherry-pick fails in about 64% of cases due to structural divergence, attributes 91.6% of those failures to target-side refactorings, and proposes RePatch, a rule-based refactoring-aware integration tool that extends RefMerge to asymmetric patch transfer. RePatch detects and inverts refactorings on both source and target, applies the patch, then replays the transformations. The paper reports that RePatch resolves 52.8% of previously failing cherry-picks. The evaluation metric is syntactic: a patch counts as successful if it applies without conflicts; no functional or test-based validation was performed, as explicitly acknowledged in Section VI.

Significance. If the reported recovery rate held under behavioral validation, RePatch would be a valuable, interpretable complement to token-based or LLM-based patch-porting tools, with direct practical benefit to clone-and-own ecosystems. The work builds on externally developed tools (PaReco for missed-patch identification, RefactoringMiner for refactoring detection), so the central result is not an artifact of fitting parameters to the target dataset. The paper also commits to releasing tools, datasets, and logs, which is a concrete reproducibility strength. However, the headline 'successfully integrates' currently rests entirely on conflict-free application, making the claimed 52.8% recovery an upper bound on true behavioral success. That caveat is load-bearing and prevents the central claim from being accepted as stated.

major comments (3)
  1. [§VI (Threats to Validity), fifth bullet; also Abstract and §I] The central metric 'successfully integrates' is defined only at the syntactic level: a patch is counted as successful if it applies without conflicts. Section VI explicitly states that 'our evaluation focused on syntactic conflict resolution and did not perform functional validation of integrated patches (e.g., via test suites).' Because RePatch's inversion and replay can introduce semantic changes while applying cleanly, the 52.8% recovery rate does not establish that the integrated patches actually fix the target bug or preserve behavior. This is load-bearing for the paper's headline claim. The authors should either add functional validation (e.g., build/test the patched variant where possible) or systematically rephrase the abstract, contributions, and conclusion to say 'applies without syntactic conflicts,' explicitly deferring behavioral correctness to future work.
  2. [Abstract vs §I; §VI timeout paragraph] The quantitative claims contain internal inconsistencies. The abstract reports a 64.4% cherry-pick failure rate, while §I reports 64.6%. Also, Section VI states that '17 patches (5.5%) exceeded this limit,' but 17/478 ≈ 3.6%, not 5.5%. If the denominator differs (e.g., only previously failing patches), that should be stated explicitly. Because the paper's contribution is empirical, these numeric inconsistencies undermine confidence in the headline numbers and should be reconciled.
  3. [§III-A (RQ2) and Contributions] The claim that '91.6% of Git cherry-pick failures are due to target-side refactorings' is a central empirical result, but the provided manuscript does not operationalize how a failure is attributed to a refactoring rather than to other causes such as deletions, interface drift, or unrelated edits. Without a documented classification rule or independent validation (e.g., manual inspection with inter-rater agreement), the attribution is not reproducible. Please specify the attribution procedure and, if manual classification was used, report reliability statistics.
minor comments (3)
  1. [Throughout] The phrase '14 divergent pair of variants' should be '14 divergent pairs of variants' (Abstract, §I, §III).
  2. [References] Several references in [26]–[40] consist only of '2025. [Online]. Available: <URL>' with no title or access date. Reference [10] contains a typo, 'V ol-2912'. Reference [23] points to GNU diffutils documentation but is labeled 'Online appendix'; please correct the title.
  3. [§III-B Step 1] The text uses a non-ASCII arrow 'source � target' (likely a LaTeX rendering issue). Use 'source → target' consistently.

Circularity Check

0 steps flagged · score 0.0 of 10

No significant circularity: RePatch's success rate is an empirically measured outcome rather than a consequence of how its inputs are defined.

full rationale

Walking the derivation chain: the paper takes missed-patch candidates from the PaReco dataset (external prior work, albeit co-authored by Businge), detects refactorings with RefactoringMiner (an independent tool), applies a rule-based invert-and-replay strategy adapted from RefMerge, and reports the fraction of previously failing Git cherry-picks that now apply without conflicts. No parameter is fitted to the target result and then renamed as a prediction; the 52.8% figure is an experimental outcome that could have been low or zero. The self-citations to [3] and [5] supply motivation and the evaluation corpus, but the central claim does not reduce to those citations: PaReco does not determine whether RePatch's inversions and replays will make hunks apply, and RefactoringMiner is not used to certify the success measure. The paper explicitly admits its success criterion is syntactic: 'our evaluation focused on syntactic conflict resolution and did not perform functional validation of integrated patches (e.g., via test suites)' (Section VI, fifth threat). That is a real limitation on what 'successfully integrates' means, but it is an inadequate-validity concern, not a circularity: the measured event (conflict-free application) is not defined in terms of the claimed explanation (refactoring awareness). The 64.4%/64.6% discrepancy for Git cherry-pick failure is a consistency error, not circularity. Because the core evaluation is self-contained against external tools and benchmarks, and the conclusions are not forced by definition or self-citation, the circularity score is 0.

Assumptions & free parameters 2 free parameters · 4 assumptions · 1 invented entities

The central claim is empirical and rests on domain assumptions rather than mathematical axioms. No free parameters are fit in a derivation sense; instead, the study outcome is shaped by hand-set experimental parameters (timeout, activity filter date). The most important assumption is that conflict-free application is a sufficient proxy for successful integration, which the paper explicitly flags. RePatch is listed as an invented entity because it is the paper's main new artifact, but it is not a hidden postulate.

free parameters (2)
  • Integration timeout = 15 minutes
    Chosen by hand to bound experimental cost; 17 patches were reported as 5.5% timed out and treated as failures, directly lowering RePatch's success rate.
  • Activity filter date = 2025-05-15
    Used to select 14 variant pairs from the PaReco dataset whose data collection ended August 2021; this selection may bias the sample toward currently active forks.
assumptions (4)
  • domain assumption RefactoringMiner accurately detects and classifies refactorings in both source and target variants.
    RePatch's invert-and-replay mechanism depends entirely on this detection; Section VI acknowledges that RefactoringMiner may miss or misclassify fine-grained or intertwined refactorings.
  • domain assumption Patches flagged by PaReco as missed opportunities correspond to bug fixes that should be propagated to the target variant.
    The evaluation set is built from PaReco's classification; if that classification is noisy, the 478-patch sample is not a reliable ground truth for integration attempts.
  • ad hoc to paper A patch that applies without syntactic conflicts is considered successfully integrated, even without functional validation.
    Section VI explicitly states that no test-suite or behavioral validation was performed, so 'success' is defined as conflict-free application; this undergirds the headline 52.8% figure.
  • domain assumption The 14 variant pairs are representative of the population of long-lived Java forks.
    The pairs are a convenience sample based on an activity filter and Java-only restriction, with no random sampling or representativeness analysis.
invented entities (1)
  • RePatch independent evidence
    purpose: Extends RefMerge to asymmetric patch transfer by inverting refactorings in both source and target, applying the patch, and replaying transformations.
    RePatch is a software artifact rather than a postulated natural entity. Its existence and behavior are externally checkable through the released Zenodo artifacts and its evaluation against Git cherry-pick, so it has a falsifiable handle outside the paper itself.

how reviews work

0 comments
Cite this review

Pith. "Pith review of Refactoring-Aware Patch Integration Across Structurally Divergent Java Forks." pith.science (2026). https://pith.science/paper/IL5Y5YAV

@misc{pith2026250806718,
  author       = {Pith},
  title        = {Pith review of: Refactoring-Aware Patch Integration Across Structurally Divergent Java Forks},
  year         = {2026},
  howpublished = {\url{https://pith.science/paper/IL5Y5YAV}},
  note         = {Machine review of arXiv:2508.06718}
}
read the original abstract

While most forks on platforms like GitHub are short-lived and used for social collaboration, a smaller but impactful subset evolve into long-lived forks, referred to here as variants, that maintain independent development trajectories. Integrating bug-fix patches across such divergent variants poses challenges due to structural drift, including refactorings that rename, relocate, or reorganize code elements and obscure semantic correspondence. This paper presents an empirical study of patch integration failures in 14 divergent pair of variants and introduces RePatch, a refactoring-aware integration system for Java repositories. RePatch extends the RefMerge framework, originally designed for symmetric merges, by supporting asymmetric patch transfer. RePatch inverts refactorings in both the source and target to realign the patch context, applies the patch, and replays the transformations to preserve the intent of the variant. In our evaluation of 478 bug-fix pull requests, Git cherry-pick fails in 64.4% of cases due to structural misalignments, while RePatch successfully integrates 52.8% of the previously failing patches. These results highlight the limitations of syntax-based tools and the need for semantic reasoning in variant-aware patch propagation.

Discussion (0). Continue with ORCID to comment.

Forward citations

Cited by 1 Pith paper

Reviewed papers in the Pith corpus that reference this work. Sorted by Pith novelty score. Full citation record

  1. Structural and Connectivity Patterns in the Maven Central Software Dependency Network

    cs.SE 2025-08 reject novelty 4.0 of 10

    A hub-centric sample of the Maven Central dependency graph shows heavy-tailed degree distributions, a giant weakly connected component, and central roles for JUnit, Hamcrest, Spring, and logging libraries.

Reference graph

Works this paper leans on

57 extracted references · 45 canonical work pages · cited by 1 Pith paper

  1. [1]

    An empirical analysis of the costs of clone- and platform-oriented software reuse,

    J. Kr ¨uger and T. Berger, “An empirical analysis of the costs of clone- and platform-oriented software reuse,” in Proceedings of the 28th ACM Joint Meeting on European Software Engineering Conference and Symposium on the Foundations of Software Engineering , ser. ESEC/FSE 2020. New York, NY , USA: Association for Computing Machinery, 2020, p. 432–444

    work page 2020

  2. [2]

    Clone-based variability management in the android ecosystem,

    J. Businge, M. Openja, S. Nadi, E. Bainomugisha, and T. Berger, “Clone-based variability management in the android ecosystem,” in2018 IEEE International Conference on Software Maintenance and Evolution, ICSME 2018, Madrid, Spain, September 23-29, 2018 . IEEE Computer Society, 2018, pp. 625–634

    work page 2018

  3. [3]

    Reuse and maintenance practices among divergent forks in three software ecosystems,

    J. Businge, M. Openja, S. Nadi, and T. Berger, “Reuse and maintenance practices among divergent forks in three software ecosystems,” Empirical Software Engineering , vol. 27, no. 2, p. 54, 2022. [Online]. Available: https://doi.org/10.1007/s10664-021-10078-2

    work page doi:10.1007/s10664-021-10078-2 2022

  4. [4]

    Variant forks – motivations and impediments,

    J. Businge, A. Decan, A. Zerouali, T. Mens, and C. D. R. Serge Demeyer, “Variant forks – motivations and impediments,” in 2022 IEEE Interna- tional Conference on Software Analysis, Evolution and Reengineering (SANER), 2022

    work page 2022

  5. [6]

    Blockchain-oriented software variant forks: A preliminary study,

    H. Rocha and J. Businge, “Blockchain-oriented software variant forks: A preliminary study,” in 5th International Workshop on Blockchain Oriented Software Engineering , 2022

    work page 2022

  6. [7]

    Con- cepts, operations, and feasibility of a projection-based variation control system,

    S. Stanciulescu, T. Berger, E. Walkingshaw, and A. Wasowski, “Con- cepts, operations, and feasibility of a projection-based variation control system,” in International Conference on Software Maintenance and Evolution (ICSME). Los Alamitos, CA, USA: IEEE Computer Society, 2016, pp. 323–333

    work page 2016

  7. [8]

    Variant- preserving refactorings for migrating cloned products to a product line,

    W. Fenske, J. Meinicke, S. Schulze, S. Schulze, and G. Saake, “Variant- preserving refactorings for migrating cloned products to a product line,” in 2017 IEEE 24th International Conference on Software Analysis, Evolution and Reengineering (SANER) , 2017, pp. 316–326

    work page 2017

  8. [9]

    Improving collaboration efficiency in fork-based develop- ment,

    S. Zhou, “Improving collaboration efficiency in fork-based develop- ment,” Ph.D. Dissertation, Carnegie Mellon University, Pittsburgh, PA, USA, 2020

    work page 2020

Show all 57 references
  1. [10]

    An empirical investigation of forks as variants in the npm package distribution,

    J. Businge, A. Decan, A. Zerouali, T. Mens, and S. Demeyer, “An empirical investigation of forks as variants in the npm package distribution,” in Proceedings of the 19th Belgium-Netherlands Software Evolution Workshop, BENEVOL 2020, Luxembourg, December 3- 4, 2020 , ser. CEUR ...

    2020

  2. [11]

    Businge, M

    J. Businge, M. Abdi, and S. Demeyer, Analyzing Variant Forks of Software Repositories from Social Coding Platforms . Cham: Springer International Publishing, 2023, pp. 131–152. [Online]. Available: https://doi.org/10.1007/978-3-031-36060-2 6

    2023 doi

  3. [12]

    An empirical study of technical debt management as a motivation for forking,

    M. Njima, J. Businge, and S. Demeyer, “An empirical study of technical debt management as a motivation for forking,” 2020

    2020

  4. [13]

    Intention-based integration of software variants,

    M. Lillack, S. Stanciulescu, W. Hedman, T. Berger, and A. Wasowski, “Intention-based integration of software variants,” in 2019 IEEE/ACM 41st International Conference on Software Engineering (ICSE) , 2019, pp. 831–842

    2019

  5. [14]

    Molhadoref: a refactoring-aware software configuration management tool,

    D. Dig, T. N. Nguyen, K. Manzoor, and R. Johnson, “Molhadoref: a refactoring-aware software configuration management tool,” in Companion to the 21st ACM SIGPLAN Symposium on Object-Oriented Programming Systems, Languages, and Applications, ser. OOPSLA ’06. New York, NY , USA: ...

    2006

  6. [15]

    Operation-based refactoring-aware merging: An empirical evaluation,

    M. Ellis, S. Nadi, and D. Dig, “Operation-based refactoring-aware merging: An empirical evaluation,” IEEE Transactions on Software Engineering, vol. 49, no. 4, pp. 2698–2721, 2023

    2023

  7. [16]

    Automating zero-shot patch porting for hard forks,

    S. Pan, Y . Wang, Z. Liu, X. Hu, X. Xia, and S. Li, “Automating zero-shot patch porting for hard forks,” in Proceedings of the 33rd ACM SIGSOFT International Symposium on Software Testing and Analysis, ser. ISSTA 2024. New York, NY , USA: Association for Computing Machinery, 2...

    2024

  8. [17]

    Synchronizing software variants with variantsync,

    T. Pfofe, T. Th ¨um, S. Schulze, W. Fenske, and I. Schaefer, “Synchronizing software variants with variantsync,” in Proceedings of the 20th International Systems and Software Product Line Conference, ser. SPLC ’16. New York, NY , USA: Association for Computing Machinery, 2016,...

    2016

  9. [18]

    Program merge conflict resolution via neural transformers,

    A. Svyatkovskiy, S. Fakhoury, N. Ghorbani, T. Mytkowicz, E. Dinella, C. Bird, J. Jang, N. Sundaresan, and S. K. Lahiri, “Program merge conflict resolution via neural transformers,” in Proceedings of the 30th ACM Joint European Software Engineering Conference and Symposium on t...

    2022

  10. [19]

    Deepmerge: Learning to merge programs,

    E. Dinella, T. Mytkowicz, A. Svyatkovskiy, C. Bird, M. Naik, and S. Lahiri, “Deepmerge: Learning to merge programs,” IEEE Transac- tions on Software Engineering , vol. 49, no. 4, pp. 1599–1614, 2023

    2023

  11. [20]

    Intellimerge: a refactoring-aware software merging technique,

    B. Shen, W. Zhang, H. Zhao, G. Liang, Z. Jin, and Q. Wang, “Intellimerge: a refactoring-aware software merging technique,” Proc. ACM Program. Lang. , vol. 3, no. OOPSLA, Oct. 2019. [Online]. Available: https://doi.org/10.1145/3360596

    2019 doi

  12. [21]

    Accurate and efficient refactoring detection in commit history,

    N. Tsantalis, M. Mansouri, L. M. Eshkevari, D. Mazinanian, and D. Dig, “Accurate and efficient refactoring detection in commit history,” in Proceedings of the 40th International Conference on Software Engineering , ser. ICSE ’18. New York, NY , USA: Association for Computing M...

    2018

  13. [22]

    Refactoring-aware patch integration across structurally divergent java forks,

    D. Ogenrwot and J. Businge, “Refactoring-aware patch integration across structurally divergent java forks,” Aug. 2025. [Online]. Available: https://doi.org/10.5281/zenodo.16756017

    2025 doi

  14. [23]

    (2021, apr) Online appendix

    GitHub. (2021, apr) Online appendix. GitHub. [Online]. Available: https://www.gnu.org/software/diffutils/manual/html node/Hunks.html

    2021

  15. [24]

    Patchtrack: Analyzing chatgpt’s impact on software patch decision-making in pull requests,

    D. Ogenrwot and J. Businge, “Patchtrack: Analyzing chatgpt’s impact on software patch decision-making in pull requests,” in Proceedings of the 39th IEEE/ACM International Conference on Automated Software Engineering, ser. ASE ’24. New York, NY , USA: Association for Computing ...

    2024

  16. [25]

    Patchtrack: A comprehensive analysis of chatgpt’s influence on pull request outcomes,

    ——, “Patchtrack: A comprehensive analysis of chatgpt’s influence on pull request outcomes,” 2025. [Online]. Available: https://arxiv.org/abs/ 2505.07700

    2025 arXiv

  17. [26]

    [Online]

    2025. [Online]. Available: https://github.com/apache/kafka/pull/13032

    2025

  18. [27]

    [Online]

    2025. [Online]. Available: https://github.com/apache/kafka/pull/12363

    2025

  19. [28]

    [Online]

    2025. [Online]. Available: https://github.com/apache/kafka

    2025

  20. [29]

    [Online]

    2025. [Online]. Available: https://github.com/DSpace/DSpace

    2025

  21. [30]

    [Online]

    2025. [Online]. Available: https://github.com/bitcoinj/bitcoinj

    2025

  22. [31]

    [Online]

    2025. [Online]. Available: https://github.com/javacc/javacc

    2025

  23. [32]

    [Online]

    2025. [Online]. Available: https://github.com/xerial/sqlite-jdbc

    2025

  24. [33]

    [Online]

    2025. [Online]. Available: https://github.com/typetools/ checker-framework

    2025

  25. [34]

    [Online]

    2025. [Online]. Available: https://github.com/linkedin/kafka

    2025

  26. [35]

    [Online]

    2025. [Online]. Available: https://github.com/ufal/clarin-dspace

    2025

  27. [36]

    [Online]

    2025. [Online]. Available: https://github.com/bisq-network/bitcoinj

    2025

  28. [37]

    [Online]

    2025. [Online]. Available: https://github.com/langerhans/dogecoinj-new

    2025

  29. [38]

    [Online]

    2025. [Online]. Available: https://github.com/tulipcc/ParserGeneratorCC

    2025

  30. [39]

    [Online]

    2025. [Online]. Available: https://github.com/Willena/sqlite-jdbc-crypt

    2025

  31. [40]

    [Online]

    2025. [Online]. Available: https://github.com/eisop/checker-framework

    2025

  32. [41]

    Operation-based merging,

    E. Lippe and N. van Oosterom, “Operation-based merging,” SIGSOFT Softw. Eng. Notes , vol. 17, no. 5, p. 78–87, Nov. 1992. [Online]. Available: https://doi.org/10.1145/142882.143753

    1992

  33. [42]

    Semistructured merge: rethinking merge in revision control systems,

    S. Apel, J. Liebig, B. Brandl, C. Lengauer, and C. K ¨astner, “Semistructured merge: rethinking merge in revision control systems,” in Proceedings of the 19th ACM SIGSOFT Symposium and the 13th European Conference on Foundations of Software Engineering , ser. ESEC/FSE ’11. New...

    2011

  34. [43]

    Lase: Locating and applying systematic edits by learning from examples,

    N. Meng, M. Kim, and K. S. McKinley, “Lase: Locating and applying systematic edits by learning from examples,” in 2013 35th International Conference on Software Engineering (ICSE) , 2013, pp. 502–511

    2013

  35. [44]

    Software reuse,

    C. W. Krueger, “Software reuse,” ACM Comput. Surv. , vol. 24, no. 2, p. 131–183, Jun. 1992. [Online]. Available: https://doi.org/10.1145/ 130844.130856 11

    1992

  36. [45]

    An empirical investigation into merge conflicts and their effect on software quality,

    C. Brindescu, I. Ahmed, C. Jensen, and A. Sarma, “An empirical investigation into merge conflicts and their effect on software quality,” Empirical Software Engineering , vol. 25, no. 1, pp. 562–590, 2020. [Online]. Available: https://doi.org/10.1007/s10664-019-09735-4

    2020 doi

  37. [46]

    Systematic editing: generating program transformations from an example,

    N. Meng, M. Kim, and K. S. McKinley, “Systematic editing: generating program transformations from an example,” vol. 46, no. 6. New York, NY , USA: Association for Computing Machinery, Jun. 2011, p. 329–342. [Online]. Available: https://doi.org/10.1145/1993316.1993537

    2011

  38. [47]

    Patchnet: Hierarchical deep learning-based stable patch identification for the linux kernel,

    T. Hoang, J. Lawall, Y . Tian, R. J. Oentaryo, and D. Lo, “Patchnet: Hierarchical deep learning-based stable patch identification for the linux kernel,” IEEE Transactions on Software Engineering , vol. 47, no. 11, pp. 2471–2486, 2021

    2021

  39. [48]

    The plastic surgery hypothesis,

    E. T. Barr, Y . Brun, P. Devanbu, M. Harman, and F. Sarro, “The plastic surgery hypothesis,” in Proceedings of the 22nd ACM SIGSOFT International Symposium on Foundations of Software Engineering, ser. FSE 2014. New York, NY , USA: Association for Computing Machinery, 2014, p. ...

    2014

  40. [49]

    Analyzing software evolution,

    T. Mens and F. Van Rysselberghe, “Analyzing software evolution,” in IWPC, 2004

    2004

  41. [50]

    Catchup! capturing and replaying refactorings to support api evolution,

    J. Henkel and A. Diwan, “Catchup! capturing and replaying refactorings to support api evolution,” in Proceedings of the 27th International Conference on Software Engineering , ser. ICSE ’05. New York, NY , USA: Association for Computing Machinery, 2005, p. 274–283. [Online]. A...

    2005

  42. [51]

    Reba: refactoring- aware binary adaptation of evolving libraries,

    D. Dig, S. Negara, V . Mohindra, and R. Johnson, “Reba: refactoring- aware binary adaptation of evolving libraries,” in Proceedings of the 30th International Conference on Software Engineering , ser. ICSE ’08. New York, NY , USA: Association for Computing Machinery, 2008, p. 4...

    2008

  43. [52]

    Refactoringminer 2.0,

    N. Tsantalis, A. Ketkar, and D. Dig, “Refactoringminer 2.0,” IEEE Transactions on Software Engineering, vol. 48, no. 3, pp. 930–950, 2022

    2022

  44. [53]

    Fowler, Refactoring: Improving the Design of Existing Code

    M. Fowler, Refactoring: Improving the Design of Existing Code . Boston, MA, USA: Addison-Wesley, 1999

    1999

  45. [54]

    Addison- Wesley Professional, 2018

    ——, Refactoring: improving the design of existing code . Addison- Wesley Professional, 2018

    2018

  46. [55]

    A survey of software refactoring,

    T. Mens and T. Tourwe, “A survey of software refactoring,” IEEE Transactions on Software Engineering, vol. 30, no. 2, pp. 126–139, 2004

    2004

  47. [56]

    When does a refactoring induce bugs? an empirical study,

    G. Bavota, B. De Carluccio, A. De Lucia, M. Di Penta, R. Oliveto, and O. Strollo, “When does a refactoring induce bugs? an empirical study,” in 2012 IEEE 12th International Working Conference on Source Code Analysis and Manipulation , 2012, pp. 104–113

    2012

  48. [57]

    The buggy side of code refactoring: understanding the relationship between refactorings and bugs,

    I. Ferreira, E. Fernandes, D. Cedrim, A. Uch ˆoa, A. C. Bibiano, A. Garcia, J. a. L. Correia, F. Santos, G. Nunes, C. Barbosa, B. Fonseca, and R. de Mello, “The buggy side of code refactoring: understanding the relationship between refactorings and bugs,” ser. ICSE ’18. New Yo...

    2018

  49. [58]

    On the relationship between refactoring actions and bugs: a differentiated replication,

    M. Di Penta, G. Bavota, and F. Zampetti, “On the relationship between refactoring actions and bugs: a differentiated replication,” in Proceedings of the 28th ACM Joint Meeting on European Software Engineering Conference and Symposium on the Foundations of Software Engineering,...

    2020

Pith tools

Reviewed August 5, 2026 · model on record in the stance chip above.