di-sukharev / di-sukharev/opencommit

[Feature]: Semantic diff that ignores pure formatting

Open
#541 0 comments 0 reactions 0 assignees View on GitHub

Nobody has claimed this yet.

Dominant language
JavaScript
Stars
7.5k
Forks
445
Avg merge
18m
Merged PRs (30d)
2

Description

Description

Currently, git diff captures pure text changes, which may include mostly irrelevant changes.
This consumes LLM tokens and creates commit message comments that bloat the message, potentially hiding important changes in the toll pile of garage messages.

Suggested Solution

I’d like to have a --semantic-diff parameter when enabled with oco, it would use diffsitter that is based on AST code changes.
https://github.com/afnanenayet/diffsitter

Alternatives

No response

Additional Context

This idea could be extended:

By still leveraging the remaining less important changes that are captured as usual git diff, but then clearly identifying and separating them as less important, that we could ask LLM to pay less attention to and produce less detailed summary.

So I could get full picture of the changes, but have LLm focus with on summarizing with more details important chances. While keeping semantically not important formatting and spend less output LLM tokens on those (potentially even using another cheaper model).

Contributor guide

Open the contributing guide

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

Research direction

Start at oco's CLI option handling and its existing git diff path; review how diffsitter provides AST-based semantic changes. Done means --semantic-diff is accepted, formatting-only changes are excluded or separated as specified, and the resulting commit-message workflow reflects the semantic diff.

Written by the indexing model from the issue text.

Assessment

Tech stack
git, javascript
Domain
cli, devtools
Issue type
Feature
Difficulty
4/5
Estimated time
3-5 days
Activity status
Stale
Clarity
Mostly clear
Newbie friendliness
35/100

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.