Cursor Git Integration: Commit Messages, Conflicts, Attribution

Yes, and it reads more than the diff. Stage your changes, then click the sparkle icon in the commit message input. Cursor generates a message based on your diff and your repo history, so the result tends to match the conventions already in your log rather than a generic template.

Whatever is staged is the whole of what the message can describe, which makes staging the selection step. Half-stage a change and the generated line describes the half and says nothing about the rest. My first instinct there was that the generator had done a bad job. It had done a fine job on a badly chosen input, so the move is to restage until one coherent change is sitting there and generate again.

What you will not get is why the change was made. That is not in the diff, and no amount of reading previous commits will produce it, so I keep the generated line as the summary and write the body myself when a reviewer would need one.

When you hit a merge conflict, the conflict UI carries a Resolve in Chat action. Agent analyses both sides and proposes a resolution, which you then accept or edit like any other diff.

Worth being clear about the word "proposes". A conflict is usually two people disagreeing about intent, and the agent is reading the code, not the intent. Read what it chose before you take it.

A resolution can also keep one side and quietly drop the other. That version compiles and reads clean, then surfaces weeks later as a feature that used to be there. Conflict markers were the only visible sign anything was in dispute, and accepting a resolution clears them.

How much that matters depends on who wrote the other side. On a team of four you can go and ask; across teams, or on a branch whose author has moved on, the two diffs are the only evidence there is. Keeping the collision from happening in the first place is a separate problem, covered in parallel agents and merge conflicts.

When Agent creates commits or pull requests, Cursor can append a Made with Cursor trailer automatically. It covers both git commits and pull requests created via gh pr create, and it is on by default.

Both rows are live at once on a team that is mid-upgrade, and that is the only reason a settings move earns a paragraph here. Any onboarding note or rollout email naming a single path is right for some of your engineers and wrong for the others, who will reasonably conclude the setting is gone. Keep both paths written down until everyone is on 3.11 or later.

Those two cases are the whole documented scope. A PR opened another way is not covered by them one way or the other, so look at one before you assume the label travels with it.

If your team cares about the trailer either way, the individual toggle is not where you settle it. That is the next section.

Yes, globally. Enterprise admins can disable commit attribution for all team members from the Admin Dashboard, under Admin Dashboard > Settings. The org-level setting overrides individual user settings, so no trailers are appended to Agent commits or PRs anywhere in the organisation.

Before a rollout, the org setting is a line in a setup doc nobody argues with. Set it after one and you are negotiating with people who already have opinions about their own commit logs, which is why the timing matters more here than the wording of the policy does. The one-way override is the other half of it, since a developer who switches attribution on late has changed nothing that reaches a commit.

On a small team you may not need the org-level setting at all. The conversation is faster than the toggle, and one decision in a channel holds well enough. It stops holding past the point where you cannot name everyone with commit access, and short-lived contractor accounts are the population least likely to have heard the decision.

The dashboard toggle is documented as on or off for the whole team, and the override Cursor spells out runs in the off direction. A policy that instead requires the label on every Agent commit is leaning on the on position doing the same job in reverse, which the help page does not say it does. Check it in the dashboard before anyone writes it into a control.

Cursor BlameAn augmented git blame that records line-level human and agent co-authorship, so you can trace which code was written by AI versus a person. Press Enter for the full definition. tracks which code was written by AI and which was written by humans, annotating your git history so you can see at a glance whether a line was AI-generated. Cursor names three uses for it: code review, auditing, and understanding your codebase's AI footprint.

Setup and usage live in the Cursor BlameAn augmented git blame that records line-level human and agent co-authorship, so you can trace which code was written by AI versus a person. Press Enter for the full definition. reference instead of on the Git help page, which is probably where you would look first. Reach for it when someone asks what proportion of a repository the agents wrote and a rough sense of it will not do.

Know which counter produced a number before you quote it at anyone in a review.

The team dashboard carries its own measure of AI share of committed code, and that one has documented blind spots. Automated formatters can invalidate the diff signatures, and Background Agents and the CLI are not covered yet (team analytics). Those caveats belong to that metric. Whether Cursor BlameAn augmented git blame that records line-level human and agent co-authorship, so you can trace which code was written by AI versus a person. Press Enter for the full definition. shares any of them is not something the Git help page says.

Of the three uses Cursor names, code review is the one I would be slowest to turn into a rule. The annotation tells you where a line came from, not whether anyone understood it, and reviewing AI lines harder sorts your attention by origin rather than by risk. Use it to decide where to look first.

Each open workspace has its own independent Agent and git context, and an agent in one window will not touch files in another. That isolation is what makes running work in two windows at once safe rather than a race.

Which covers less ground than it sounds like. What Cursor documents is isolation per workspace, and for two windows holding two different repos that is exactly what you want. Two agents on one repo is a different problem, and the tool for it is a worktree, an isolated Git checkout you can start from the Agents WindowCursor's surface listing your agent runs; open a run to read its diff and search transcripts from the command palette. Press Enter for the full definition..