A small bug fix often turns into a mixed diff. You correct a calculation, then improve the output while the file is open. Both edits belong in the project, but they answer different questions in review.
Start with two reasons to change one file
Consider this small Python example in orders.py:
def order_total(prices, discount=0):
subtotal = sum(prices)
return subtotal - discount
def format_currency(amount):
return f"${amount:.2f}"
def validate_currency(currency):
return currency in ("USD", "EUR")
def item_count(prices):
return len(prices)
def order_summary(prices):
return format_currency(order_total(prices))
The first change prevents a discount from producing a negative total:
- return subtotal - discount
+ return max(0, subtotal - discount)
The second adds a label to the summary:
-def order_summary(prices):
- return format_currency(order_total(prices))
+def order_summary(prices, label="Order"):
+ return f"{label}: {format_currency(order_total(prices))}"
These edits deserve separate review. The clamp changes a calculation rule. The label changes the returned text, including the default output, so callers or tests expecting only a currency string may need updating. Giving it a separate commit makes that behavior change explicit.
The useful boundary is the reason for each edit, not the filename. A reviewer should be able to assess the calculation fix without also deciding whether the new output format is appropriate.
You can do the split manually
In IntelliJ IDEA, open the Commit window and inspect the file's diff. Select the calculation chunk and leave the label chunk unselected. Commit the fix, then review and commit the remaining change. JetBrains also supports moving chunks into different changelists and committing those lists separately. Its partial-commit documentation covers both approaches.
A changelist groups uncommitted local changes; it is not a separate Git branch. Review the selected chunks again before each commit, especially if you kept editing after organizing them.
From the terminal, start with an empty staging area and use Git's interactive patch selection:
git add -p -- orders.py
git diff --cached
Accept the fix hunk and reject the label hunk. If Git presents a combined hunk, use s when splitting is available. Check the complete staged diff before committing; git diff shows what remains unstaged. This is a good fit when the intended split is already obvious.
Watch a reviewed AI suggestion
Load the 58-second demonstration from YouTube. Loading the player connects your browser to YouTube.
Watch the 58-second demonstration on YouTube.
The recording uses the public SmartChangelist AI 4.0.0 package in PyCharm 2026.2.2 with GPT-4.1 mini. It contains real IDE captures, with shortened pauses and English captions. The closing card describes the original local preparation; the video was subsequently uploaded for this walkthrough.
Configure a provider and model in SmartChangelist settings, keep preview enabled, then run Reorganize Changes. The model proposes groups and messages. Inspect every proposed hunk before applying the grouping, and inspect the resulting native changelists before committing.
In this example, the model placed the calculation fix and the label change into different groups. It called the second change refactor, however. I corrected that prefix to feat in the native commit dialog because the edit changes observable output. A plausible message is still a suggestion.
The first native IDE commit contained only the clamp. The label edit remained pending and became the second native commit. I checked both commits against Git's stored contents: the final file matched the original working changes, and a separate control file was unchanged.
Keep the review and data boundaries explicit
The added step is a proposed grouping inside the IDE. It can give you a starting point when a working tree mixes concerns, but it does not establish that the changes are independent or correctly implemented. Check dependencies between edits and run the relevant tests for each resulting commit.
Earlier local-model attempts in this recording session timed out or omitted one hunk. Those proposals were canceled. One successful hosted-model example does not establish a success rate, faster reviews, or reliable behavior on larger diffs.
SmartChangelist AI is a paid plugin. Hosted providers use your API key, and their charges are separate. This OpenAI run sent example change context to OpenAI before the preview appeared; preview is a review step for the grouping, not a consent step for that transmission. Choose an endpoint you are permitted to send the code to before running the action.
If reviewed suggestions would help with your mixed diffs, see SmartChangelist AI's setup and requirements.