Query `git` state to get information on a currently ongoing rebase when encountering conflict markers

[estebank]

Proposal

The rustc parser currently identify patch conflict markers that are caused when trying to merge or rebase code in many different code-control systems, including git. git is the most common amongst our users, so our diagnostic does provide some additional context for them. I'm proposing invoking git to get its .git/rebase-merge directory, which holds the metadata needed by git to understand where it is in a rebase. We can use the same information to surface what the target branch name is, the origin branch name is, and differentiate between a merge conflict caused by git rebase branch-name and git pull. There are other sources of conflict markers in git (like git stash pop and git merge) and other VCSs that could also be supported.

An implementation is present at rust-lang/rust#150233.

Mentors or Reviewers

I'll mentor and review any additional work beyond the above PR.

Process

The main points of the Major Change Process are as follows:

• File an issue describing the proposal.
• A compiler team member who is knowledgeable in the area can second by writing @rustbot second or kickoff a team FCP with @rfcbot fcp $RESOLUTION.
  • Refer to Proposals, Approvals and Stabilization docs for when a second is sufficient, or when a full team FCP is required.
• Once an MCP is seconded, the Final Comment Period begins.
  • Final Comment Period lasts for 10 days after all outstanding concerns are solved.
  • Outstanding concerns will block the Final Comment Period from finishing. Once all concerns are resolved, the 10 day countdown is restarted.
  • If no concerns are raised after 10 days since the resolution of the last outstanding concern, the MCP is considered approved.

You can read more about Major Change Proposals on forge.

Caution

Concerns (1 active)

• not worth the complexity

Managed by @rustbot—see help for details.

[rustbot]

Important

This issue is not meant to be used for technical discussion. There is a Zulip stream for that.
Use this issue to leave procedural comments, such as volunteering to review, indicating that you second the proposal (or third, etc), or raising a concern that you would like to be addressed.

Concerns or objections can formally be registered here by adding a comment.

@rustbot concern reason-for-concern
<description of the concern>

Concerns can be lifted with:

@rustbot resolve reason-for-concern

See documentation at https://forge.rust-lang.org

cc @rust-lang/compiler

[nnethercote]

@rustbot concern not worth the complexity

• The existing diff marker detection already has a complexity cost, making the lexer code more ugly.
• As soon as you see a diff marker in the error message, it's clear what the problem is. You don't need lots of detail explaining exactly what happened within git. I never read the message details.
• A complete git newcomer might be surprised by diff markers, in which case a pointer to an explanation of diff markers might be helpful. But a detailed breakdown is not likely to be useful in general.
• Running git or inspecting git state could be very surprising/alarming to users.