Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[Feature]: Support only one line commit message and adjustment type #409

Open
vs-leoli opened this issue Sep 5, 2024 · 4 comments
Open

Comments

@vs-leoli
Copy link

vs-leoli commented Sep 5, 2024

Description

  1. The current commit is divided into individual messages for each file, but sometimes the entire function will affect different files. I hope there is only a single line of commit message that includes the results of multiple files combined.

  2. Also, sometimes the type of commit judged by OCO differs from my perception. I hope there can be an option to choose what type of current commit it is, such as OCO thinks it's a fix but I might think it's a feat.

Suggested Solution

The current format is:

fix (filename): description
feat (filename): description

I hope it can be changed to:

fix: description of all of the files

Assume the current result generated by OCO is:

fix (filename): description

I hope it can be adjusted to other types, such as:

feat (filename): description

Alternatives

No response

Additional Context

No response

@di-sukharev
Copy link
Owner

absolutely agree, it's actually a kinda bug, but also an expected behaviour

do you want to make a PR to fix? if yes, please note this would require changing the prompts in all the languages, not a big deal though

  1. the config OCO_ONE_LINE_COMMIT already exists
  2. it doesnt work because of the few shots we send to the model, that are showing an example of a good commit message and it's kinda overwriting the OCO_ONE_LINE_COMMIT intention
  3. it's because of this two fix(server.ts) and feat(server.ts), so we need to adjust the example we send to openai

but you seee.. its kinda what is expected in a conventional commit convention when you commit a fix and feat changes together.. so you should not be doing that if you want fix: description of all of the files or feat: description of all of the files being a single line.

But, what i see as a good solution here is:
2. add simple option to OCO_PROMPT_MODULE, so it doesnt behave like a conventional commit, but rather as a simple (aka regular) commit message like did this thing and this thing
3. add a separate few shot for example all the i18n, similar to this
4. and adjust the system prompts here, and here

@matscube wdyt?

@XargsUK
Copy link

XargsUK commented Sep 6, 2024

Saw this after running into a similar issue. Another option could be to break these into individual commits.

So rather than a single commit with multiple lines, it responds with a recommendation for multiple commits, the files in each commit, and the commit message of each. This keeps to the principle of small incremental changes affecting individual parts of logic.

@di-sukharev
Copy link
Owner

di-sukharev commented Sep 6, 2024

@XargsUK also thought exactly about it, we would split git diff into separate contexts and make several commit messages in a row. we already do split changes into standalone git diffs when changes are too big, look at splitDiff function for reference, but the change you proposed would anyway require more work that this:

  1. simple option (i would go with as an MVP) — make a commit per file (#problem — would fail when same file has both fix and feat changes like in the few shots)
  2. a bit more effort (but solves the #problem described above) — do a commit message per change context per file, so it's actually a fix or feat only (this would require asking an llm to first do split a file git diff into separate smaller git diffs by context and then we make multiple commits. A simplified JSON response from an LLM would be like:
[
  {context: 'fix', lineStart: number, lineEnd: number},
  {context: 'feat', lineStart: number, lineEnd:number},
  {context: 'feat', lineStart: another_number, lineEnd: another_number}
]

i'd merge same contexts into one though

@matscube
Copy link
Contributor

@di-sukharev

About modifying the prompt format

How about adding a feature that allows users to directly edit the prompt?
As far as I can see from Issues, there are a lot of requests to customize the commit message individually, but it doesn't seem realistic to implement a flag for each individual request.
This is because opting-in for one feature may raise concerns that another feature may not work properly.
Adding instructions to the system prompt alone will not produce accurate output without changing the few-shot examples, but it seems that it will eventually reach its limit to continue preparing dedicated few-shot examples for various combinations of flags.

How about limiting the responsibility of this tool by allowing users to customize their own system prompts and few-shot examples, and tune their prompts themselves?
For example, something like this:

  • oco config set OCO_PROMPT_MODULE=user-config
    => A prompt configuration file (.opencommit-prompt.js) is created
    => Set the prompt used by conventional-commit as a preset

  • User edits the prompt configuration file as they like

  • User edits the source code (git diff occurs in the working repository)

  • oco tune
    => Perform tuning of the prompt configuration file
    => Generate a commit message from the current git diff and the prompt configuration file
    => User modifies the prompt configuration file until they are satisfied

Dealing with cases where the generated message is different from the intention

In the oco command, you cannot directly edit the generated commit message or give instructions if it is different from your intention. (You can only regenerate it)
Adding a feature that allows users to input their intentions when regenerating it and append them to the prompt may help bring the output closer to the user's intention than simply regenerating it.
Also, for users who are concerned about the accuracy of the commit message, it may be a good idea to recommend using the pre-commit hook, as it allows you to directly overwrite the message itself.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

4 participants