Source-linked AI summary
D-Diff: An Interactive Environment for Adjusting Commit Boundaries Based on an Editable 3-way Diff
Daiki Muto, Takayoshi Ueno, Shinpei Hayashi
TL;DR
Mixed-intention commits require developers to inspect and correct boundaries, but existing tools make consecutive diffs difficult to compare. D-Diff provides an editable three-way view of two consecutive diffs, reducing median adjustment time from 530 seconds to 230 seconds in an eight-participant study while improving usability ratings.
Problem
Existing tools show only one diff or fail to show the two consecutive diffs explicitly, making manual commit-boundary adjustment difficult to compare.
Method
D-Diff uses an interactive three-way diff for two consecutive commits involving the same single file, with direct editing and change movement.
Results
530 seconds versus 230 seconds: D-Diff significantly reduced median adjustment time by about 57%, received higher usability ratings, and showed no statistically significant accuracy difference.
Takeaways & Limitations
D-Diff supports comparing and modifying consecutive diffs in one view without relying on memory, within its single-file, two-commit scope.
Takeaways & Limitations
The study used eight participants, limiting power to detect small effects and leaving participant-task confounding that cannot be removed analytically.
Abstract
from arXiv · showhide
In version control, it is recommended that each commit include only changes related to one task. To follow this recommendation, developers may need to adjust commit boundaries, that is, to compare and modify the diffs between two consecutive commits. Existing tools either display only a single diff at a time, forcing developers to rely on their memory when comparing diffs, or display three files simultaneously without showing the two consecutive diffs, forcing developers to infer them; both increase their cognitive load and hamper the adjustment. As a first step toward supporting this process, we propose D-Diff, an interactive diff adjustment environment for two consecutive commits that each involve the same single file. Based on a 3-way diff display, D-Diff integrates the two diffs into a single compact view, which also provides a way to modify them. A within-subjects user study with 8 participants showed that D-Diff significantly outperforms a baseline tool in terms of efficiency, reducing the median adjustment time from 530 seconds to 230 seconds (approximately 57%). D-Diff also received a higher percentage of positive responses across all usability questionnaire items, while no statistically significant difference was found in accuracy.
I. INTRODUCTION
Adjusting commit boundaries helps developers turn mixed-intention commits into task-focused commits, but existing workflows make comparing consecutive diffs cognitively demanding. D-Diff addresses this by combining simultaneous diff comparison with editable boundary manipulation.
- Task Level Commits contain changes related to one task, whereas Composite Commits mix multiple intentions and hinder understanding, reuse, and reverting.
- Automatic splitting rarely matches developer intent because what counts as a single task varies across organizations and projects.
- Existing tools either show one diff at a time or show three files without the two consecutive diffs, forcing developers to rely on memory or infer differences.
- D-Diff combines simultaneous comparison of two consecutive diffs with line-level, hunk-level, and direct editing operations in one environment.
- 530 seconds versus 230 seconds: D-Diff reduced median adjustment time by about 57% compared with the baseline, with higher usability ratings and no significant accuracy difference.
III. RELATED WORK
Related tools support commit-history modification, change untangling, and three-way visualization, but they do not present editable consecutive diffs and their shared boundary together. D-Diff is positioned to address this combination of limitations.
- Interactive rebase, partial staging, and GUI clients provide general-purpose ways to reorder, combine, split, or stage commit changes.
- Change-untangling tools automatically group changes into task-related sets, but their editing is limited to regrouping a single decomposed diff.
- Diff-visualization research enriches conventional diffs with semantic annotations, fine-grained changes, or structural information.
- Three-way diff displays present three source versions, but diff3 lacks editing and vimdiff does not directly show the two consecutive diffs.
- Merge editors place conflicting versions beside a result, assuming divergent changes from a common base rather than consecutive diffs in linear history.
- Jujutsu editors allow direct intermediate-version editing, yet display only the source commit’s diff and require inspecting resulting diffs separately afterward.
IV. D-DIFF: A DIFF ADJUSTMENT ENVIRONMENT
D-Diff treats the intermediate version shared by two consecutive diffs as an editable commit boundary. Its three-way display materializes correspondence between the diffs while supporting direct editing and movement of changes.
- D-Diff scopes its first solution to two consecutive commits involving the same single file, which can decompose some broader cases into per-file and consecutive-pair adjustments.
- The environment simultaneously visualizes two consecutive diffs and provides direct editing and movement operations for modifying them.
- The shared intermediate version serves as one common coordinate, so each line’s role in both commits and an edit’s dual effect appear together.
B. Comparison
D-Diff uses three side-by-side source versions to represent two consecutive diffs and offers both structured movement and unrestricted boundary editing. Its operations trade effort against granularity.
- B. Comparison: The left-to-center difference represents the first commit, while the center-to-right difference represents the second commit.
- B. Comparison: Green denotes additions and red deletions; diagonal green-red stripes mark content that is both added in one diff and deleted in the other.
- C. Modification: Moving changes is the primary operation because it requires less effort, while direct editing supports finer modifications such as separating changes within one line.
- C. Modification: Direct editing modifies the center source code, allowing developers to place the commit boundary at any position.
- C. Modification: Line-level movement handles individual lines, while hunk-level movement handles consecutive-line groups but can be too coarse for large hunks.
- C. Modification: Clicking a movement button replaces the corresponding center content with an outer version, transferring the change across the commit boundary.
- C. Modification: Figure 3 contrasts the initial state with line-level movement of Line 6 and hunk-level movement of Lines 5–6 into the first commit.
D. Implementation
D-Diff implements a 3-way diff environment that aligns two consecutive diffs around an editable shared boundary. The study evaluates its usefulness through accuracy, efficiency, and usability research questions.
- Implementation: D-Diff displays three versions of one file, with the center version shared as the boundary between the two commits.The two diffs are constructed from (s, s′) and (s′, s′′).
- Implementation: Line-level construction computes two diffs, aligns both outer versions to the center, and pads rows so all three columns remain synchronized.The center acts as the shared anchor for composing the pairwise diffs.
- Implementation: Character-level diffing classifies changes within each hunk using two character-level comparisons and semantic cleanup for readability.The comparisons cover s versus s′ and s′ versus s′′.
- Implementation: The rendered editors are scroll-synchronized, while only the center editor is editable and movement controls support boundary adjustment.Line and character classifications are shown through background colors and highlighting.
- Evaluation: The evaluation asks whether D-Diff improves accuracy, efficiency, and usability compared with a baseline in a within-subjects user study.Participants used both tools before completing questionnaires.
A. Experimental Setup
The experiment compares D-Diff with a practical VS Code and GitLens baseline using a purpose-built dataset of eight single-file TLC pairs. Tasks were generated by moving lines across correct commit boundaries.
- Tools: VS Code with GitLens serves as the baseline because general VCS workflows adjust existing boundaries through interactive rebasing.GitLens supplies GUI support for operations missing from standard VS Code.
- Dataset: The dataset was created because suitable tasks require both a misplaced starting boundary and a known correct boundary for scoring.Such cases are rare in shared repository histories.
- Dataset: 1,410 TLC sequences were reduced to 536 length-2 commit pairs, then to 30 pairs where both commits changed the same single file.The final experiment used only pairs satisfying the proposed approach’s scope.
- Dataset: Visual inspection selected 8 TLC pairs whose commit messages accurately described the changes and whose changes were suitable for the experiment.Commit messages guided participants toward the intended result.
- Task preparation: For each selected pair, 20% of changed lines were randomly moved to the opposite commit and the process was repeated until boundaries remained syntactically correct.Lines changed in both commits were moved together.
B. Experimental Process
Eight computer-science students adjusted commit boundaries with both tools under a counterbalanced design. Accuracy was measured by how much the resulting center source code approached the known correct version.
- Participants: Eight participants with at least two years of Java experience completed the study after receiving preliminary explanations and tutorials.Participants were recruited from the authors’ affiliated institution.
- Study design: A 4 × 4 Williams Latin square counterbalanced tool and task assignments to reduce order, learning, and carryover effects.Each task appeared equally in every position.
- Procedure: Participants adjusted boundaries using assigned tools and followed original TLC commit messages as task guidelines.Baseline times were obtained from screen recordings or self-report when one recording was lost.
- Accuracy measure: Accuracy used an improvement rate based on the Levenshtein distance from each participant’s output to the correct center source code.Whitespace counted as ordinary characters.
- Accuracy measure: Imp = 1 denotes a perfect match, Imp = 0 no improvement, and negative values deterioration; the metric is treated as a proxy rather than validated accuracy.It scores character-exact distance to one reference, so formatting differences count as errors.
- Analysis: Participant-level comparisons used each participant’s median over four tasks per tool and a Wilcoxon signed-rank test on eight within-participant pairs.A complementary per-task analysis was also performed.
2) Results and Discussion:
D-Diff reduced adjustment time substantially and significantly, but accuracy did not differ significantly between tools. Improvement rates were lower for tasks requiring in-line separation, which often demanded recognizing mixed changes.
- Accuracy: D-Diff’s median improvement rate exceeded the baseline overall, but the difference was not statistically significant.Participant-level and per-task tests yielded p = 0.5469 and p = 0.9165, respectively.
- Accuracy: Tasks A3, B3, and B4 had low improvement rates because they required in-line separation of changes within a single line.Participants often failed to notice that one line mixed changes from both commits.
- Accuracy: No statistically significant accuracy difference was found, and in-line-separation tasks generally produced lower improvement rates than other tasks.Task A3 additionally required domain knowledge about a Joda-Time default.
2) Results and Discussion:
D-Diff was faster than the baseline, with participants consistently completing adjustments more quickly and reporting lower cognitive burden. The efficiency difference was statistically significant, while screen-switching and participant comments provide descriptive support for the cognitive-load explanation.
- Efficiency: 530 seconds versus 230 seconds: D-Diff reduced median adjustment time by 300 seconds, or 57%, compared with the baseline.Every participant was faster overall with D-Diff.
- Efficiency: p = 0.0078 and Cliff’s delta = 0.8438: D-Diff’s time reduction was statistically significant with a large effect size.The complementary per-task analysis also found a significant difference (p = 0.0156).
- Cognitive load: 18.6 screen switches per task: participants switched screens with the baseline, whereas D-Diff uses a single screen by design.These switch counts are descriptive corroboration rather than an independent test because they come from the same recordings as the baseline times.
- Cognitive load: Participant comments associated the baseline with working-memory demands and D-Diff with easier operation across multiple screens.The responses suggest that D-Diff mitigated the memory load imposed by the baseline workflow.
- Interpretation: D-Diff’s efficiency advantage may partly reflect the task design because its move operations directly address the injected whole-line errors.The authors also relate the difference to more intuitive operation with D-Diff.
2) Results and Discussion:
D-Diff received more positive usability responses than the baseline across comparison questions, while its individual features were generally viewed as easy to use. Hunk-level movement received fewer positive responses in the small-scale tasks, and participants requested clearer deletion and addition colors.
- Tool comparison: D-Diff had a higher percentage of positive responses than the baseline for every usability question.The comparison covered understanding and modifying source-code changes as well as ease of comparison.
- Tool comparison: D-Diff was rated easier for comparing changes, understanding the modified source state, and modifying through moving or editing.Participants also reported lower perceived task-completion time and mental burden, and willingness to use D-Diff.
- Feature usability: More than half of responses were positive for every D-Diff feature, with all participants agreeing on simultaneous diff display and line-level movement.Hunk-level movement received comparatively fewer positive responses.
- Feature usability: Small-scale experimental diffs limited use of hunk-level movement, and participants requested clearer background colors for deletions and additions.The requested color clarification concerned the visual distinction of change types.
F. Threats to Validity
The study evaluates D-Diff as an integrated environment rather than isolating the effect of its 3-way display. Differences in tool functionality, tutorials, and participants’ limited baseline familiarity constrain interpretation of the results.
- Internal validity: The study could not isolate the 3-way display because D-Diff and the baseline differed in functionality and required different adjustment operations.The authors leave comparison with a separate two-diff-view variant for future work.
- Internal validity: Questionnaire responses may have favored D-Diff because participants could infer which tool was proposed from tutorials of different lengths.The authors state that this demand characteristic most affects usability results and least affects timing.
- Internal validity: Limited participant proficiency with interactive rebase may partly explain the large timing difference, despite baseline tutorial and practice.This boundary particularly affects interpretation of the baseline workflow comparison.
2) Construct Validity:
D-Diff’s evaluation supports an efficiency and usability advantage over the baseline, but accuracy measurement, statistical power, and generalizability remain constrained. The tool’s current scope and evaluation setting limit how broadly these findings can be applied.
- Construct validity: The character-level Levenshtein improvement rate may not capture semantic differences in adjustment accuracy.The measure cannot represent semantic differences between results.
- Construct validity: The line-level injected errors favor move-based correction, so the efficiency advantage may not extend to adjustments requiring more than moving.
- Conclusion validity: The study’s small sample and task-participant confound limit statistical power, and nonsignificant accuracy differences do not establish tool equivalence.The primary tests use 8 within-participant pairs, while task difficulty is balanced across participants rather than within each pair.
- External validity: With 8 computer-science student participants and four Java repositories, findings may not generalize to all developers, languages, or real tangled commits.The tasks used artificially generated TLC pairs with randomly altered boundaries, and practice frequency was not empirically measured.
- Scope: D-Diff currently targets two consecutive commits involving the same single file, leaving broader file, sequence, IDE, and fine-grained editing scenarios for future work.Proposed extensions include cross-file comparison, longer commit sequences, IDE integration, and inline separation.