Ability to customize the prompt for generating git commit message

[heyanurag]

Summary

The git integration works really good and the automatice commit message generation is a great addition!

However, my org uses commitlint and a pre-commit hook. Commitlint expects commit messages to begin with prefixes such as feat: new feature or fix: tests. So whenever I generate a commit message using Zed and try to commit, the pre-commit hook fails because the generated commit messages do not have the prefix.

I went through the code and found commit_message_prompt.txt file.

This is where the prompt is used in the method that generates the commit message.

It would be nice to be able to customize this prompt or if Zed can automatically read my commitlint.config.js file and generate commit messages accordingly!

Zed Version and System Specs

Zed: v0.178.2 (Zed Preview) OS: macOS 14.5.0 Memory: 16 GiB Architecture: aarch64

[nerjs]

Sounds like a great idea to me. I ran into the problem that deepseek wrapped the commit text in ``` . And there is no way to fix it except through PR

[hoodie]

I would love to see semantic commit messages as well. Maybe we don't even need to be able to read the commitlint.config.js. A simple flag to turn on semantic commit messages would suffice or better: just read the git log to derive the format.

like

You are an expert at writing Git commits. Your job is to write a short clear commit message that summarizes the changes.

If you can accurately express the change in just the subject line, don't include anything in the message body. Only use the body when it is providing *useful* information.

Don't repeat information from the subject line in the message body.

Only return the commit message in your response. Do not include any additional meta-commentary about the task. Do not include the raw diff output in the commit message.

Follow good Git style:

- Separate the subject from the body with a blank line
- Try to limit the subject line to 50 characters
- Capitalize the subject line
- Do not end the subject line with any punctuation
- Use the imperative mood in the subject line
- Wrap the body at 72 characters
- Keep the body short and concise (omit it entirely if not useful)

Here is an example of previous commit messages in this repository, please follow the existing style:
{include!("git log")}

[lucastnr]

That'd be a great addition, I'm supportive of that. Another approach would be to have the context of previous written commits too.

[mkykode]

Please add semantic commits (conventional commits)! They are widely used in professional work. We can either include it as a setting or implement the /prompt functionality to add context to the LLM.

[matthewmorek]

I would love a way to customize the default commit message prompt entirely, since that's what I currently use to generate commit messages using a combination of Gitmoji and conventional commits via Raycast AI integration, kicking it off like this:

$ git diff --cached | pbcopy; open raycast://ai-commands/generate-git-commit-message

I'd love to dump the contents of the prompt I used with Raycast to Zed and never having to exit Zed again!

[JosephTLyons]

I think this makes a lot of sense. We should definitely make this flexible so that it can be tailored to the needs of those using different commit message formats. I think we can just make this a normal zed setting, with support for per-project customization in the .zed directory.

[joaosouzacoder]

Hi! I’d love to contribute to this feature. I’ve already implemented a version that allows users to change the default commit behavior through the Zed settings panel.

If no custom setting is defined, it gracefully falls back to the current default behavior, so nothing breaks for users who don’t configure it.

Would it be okay if I open a pull request for this? Let me know if there’s anything specific you’d like me to adjust before submitting.

Thanks!

[jpike88]

This feature is borderline useless as it is, I'll need some kind of project-level system prompt to stop messages like this:

Add task for building client in production mode

client: Add device version info to Intercom user attributes

AI: I'll craft a clear git commit message for these changes.

Add new production build task and device version info

Set up a dedicated task for building the client in production mode, and
add device-specific version information to Intercom user attributes to
improve tracking and support.

[imumesh18]

Hey @notpeter sorry to tag you here but saw you were the reviewer of last PR opened for this issue. As this issue has been opened for quite sometime. I wanted to check what will be the acceptable approach from zed team. Given that last two prs were closed due to the same.

Option 1:

Add a config parameter within the agent.inline_assistant_model.prompt which will then be used by the agent as a base prompt to perform the action.

Option 2:

A bit more complicated but I think we can let user define the a rules_id inside of the agent.inline_assistant_model which the llm can use to generate the commit and can update the prompt from rules library. If no rules defined then fallback to the existing behaviour.

Would love your opinion on this. Seems like something which users expect coming from other editors to work out of the box. I can raise a PR we can finalise a approach which is acceptable by zed team here.

[laosb]

I will also add that judging from Zed team's response to both PRs, maybe Zed team is designing something big to fulfill this.

As a user I trust Zed team's plans & priorities, but I really hope that if it gonna take a bit more time to cook, we can at least have a stopgap solution for now.

[notpeter]

@imumesh18 Marshall mentioned that they would like to integrate with the .rules and the Rules Library which seems reasonable. That's obviously a much bigger lift than just reading from a random file provided via a settings key -- as an aside we very much try to avoid adding a new settings, particularly for things like this. For example, integrating the entire prompt in settings.json is ugly (no newlines, etc) and pointing to a file has some complications. Specifically, when validating settings.json it requires an additional step (does the file exist, is it readable) and there is currently no nice existing mechanism for validating external filesystem references when loading settings. And a validity may change at runtime (file gets deleted, etc).

For reference, the current commit_message_prompt.txt is statically included at compile time: https://github.com/zed-industries/zed/blob/05692e298a1b9d5a28b5d47eb23ca475ecda15b9/crates/git_ui/src/git_panel.rs#L1765

A stop-gap solution might be to re-use the same old-style Assistant Rules Templates handlebars templates system used by terminal_assistant_prompt.hbs and the inline assist. These are pretty ugly, and cannot be set at the project level only via ~/.config/zed/prompt_overrides, but at least can be a little bit dynamic. Honestly though, I think we're hoping to gut this too in the near future.

At the core though, it's because we want to offer something better than just referencing an external plaintext file. Ideally, these would be rules within your project, potentially enabling selecting amongst multiple templates (e.g. bugfix, feature, etc) which could be version-controlled and easily editable. Potentially these could be dynamic files (think handlebars templates) which could have different instructions for different models, support injecting context from N recent commits, etc.

I am not aware of prior art here and as a result this will may require some design/architecture exploration before it's fully implemented. In my research it appears windsurf does not respect rules for commit messages, cursor has no specific commit message rules guidance (unsure whether they are respected) and I don't believe there is any way to control the prompt for VSCode/Copilot or Claude Code. Part of what we want to avoid is implementing something and then having to deprecate it in a few months.

Sorry I don't have a better answer.

P.S. Please stop commenting "I want this!" / "me too!" or your desired commit message prompts, it's a distraction that doesn't help.

[imumesh18]

Hey @notpeter got it. Thanks for writing a detail answer. Just for context:

This is how vscode does it currently:

  "github.copilot.chat.commitMessageGeneration.instructions": [
    {
      "text": "Use conventional commit message format."
    }
  ],

This is how gitlens does it.

"gitlens.ai.generateCommitMessage.customInstructions": "Use conventional commit message format.",

Yaa cursor, windsurf or claude haven't been able to come up with something for this using rules yet and don't allow providing custom. Prompt.

I agree with you it makes more sense to somehow support it via rules editor. Might give some more thought around this to see if I can come up with a better proposal by including your insights. Thanks again for writing a detail answer helps a lot.

[mkykode]

Perhaps if we could add some context like this to the auto-generated text, the llm would take care of it.

# Commit

Create well-formatted commits with conventional commit messages and emojis.

## Features:
- Runs pre-commit checks by default (lint, build, generate docs)
- Automatically stages files if none are staged
- Uses conventional commit format with descriptive emojis
- Suggests splitting commits for different concerns

## Usage:
- `/commit` - Standard commit with pre-commit checks
- `/commit --no-verify` - Skip pre-commit checks

## Commit Types:
- ✨ feat: New features
- 🐛 fix: Bug fixes
- 📝 docs: Documentation changes
- ♻️ refactor: Code restructuring without changing functionality
- 🎨 style: Code formatting, missing semicolons, etc.
- ⚡️ perf: Performance improvements
- ✅ test: Adding or correcting tests
- 🧑‍💻 chore: Tooling, configuration, maintenance
- 🚧 wip: Work in progress
- 🔥 remove: Removing code or files
- 🚑 hotfix: Critical fixes
- 🔒 security: Security improvements

## Process:
1. Check for staged changes (`git status`)
2. If no staged changes, review and stage appropriate files
3. Run pre-commit checks (unless --no-verify)
4. Analyze changes to determine commit type
5. Generate descriptive commit message
6. Include scope if applicable: `type(scope): description`
7. Add body for complex changes explaining why
8. Execute commit

## Best Practices:
- Keep commits atomic and focused
- Write in imperative mood ("Add feature" not "Added feature")
- Explain why, not just what
- Reference issues/PRs when relevant
- Split unrelated changes into separate commits

[northes]

Would you mind .rules or a similar file to write the rules that generate the commit information and put the historical commit information in the context for LLM reference

[nazriel]

Hi, I am also interested in the matter.

I can imagine that .rules would need some parameter that would narrow it down to context in which rule can be used. Something like

context: agent|thread|completion|git

But while there is still brainstorming going on,

Would intermediate solution like migrating commit_message_prompt.txt to a system similar to the zed/assets/prompts/ where zed/assets/prompts/git_commit_message_prompt.hbs could live and be overridable with ~/.config/zed/prompt_overrides/git_commit_message_prompt.hbs be acceptable?

I did small POC here: https://github.com/nazriel/zed/commit/9821fc66fe36b0473f5ebb79718f937fab3f2e51 Seems to be working ok with

❯ cat ~/.config/zed/prompt_overrides/commit_message_prompt.hbs
You are an expert at writing Git commits. Your job is to write a short clear commit message that summarizes the changes.

...

- Always start subject with "YES!!!!"
- Be funny, use pirate voice for messages
-

gives

which is exactly what I needed

[sFritsch09]

Hey ZED Devs,

Please checkout my open discussion here, I think the hooks feature by Kiro IDE is one of the best agentic ability out there! This could trigger the generated commit message event whenever you make a commit.

Hooks 🪝 pre:commit - Generate Commit Message

[jdu211171]

Love to have this feature

[aarononeal]

Until a more sophisticated rules-based, repo-scoped design is figured out, the proposal from @nazriel would be a helpful stop-gap for some workflows. It's a scoped change that doesn't alter much if it needs to be superseded later.

[Wykaz]

In addition to custom prompts, it would be a great idea to have a text box to provide more details about the commit for the generation, because with just a prompt, it might not understand the full context of the commit..

[ValentinKolb]

This would really be a really useful feature! Maybe just add an commit.hbs alongside the other prompt templates that users can customize?

[jorgejhms]

Is there a way to chose the output language? My team uses spanish for all the commits. Would be great to have a language selecction or a way to include it in the propmt.

[dmythro]

Some IDEs can accept *.md files in configuration, with commit message generation rules. Just saying! :)

My use case: use conventional commits + specify to be as brief as possible + some sauce for cases like upgrading packages (specify their versions before/after) + longer description after an empty line etc. Saves a lot of time for me.

[ben-heimberg]

This feature is would be a reason for me to fully adopt zed in my job