Re: Metadata for merge conflicts during rebase (to aid rustc) and potential for better user experience?

On Mon, Dec 22, 2025 at 1:56 PM D. Ben Knoble [off-list ref] wrote:

On Mon, Dec 22, 2025 at 9:31 AM Esteban Küber [off-list ref] wrote:

quoted

The questions I have are:
 - can I *avoid* `--points-at` in any way to identify what branch we're
   rebasing onto?

According to "git help rebase", ORIG_HEAD is not reliable but @{1} should be.

After talking with other members of the compiler team, people have
concerns about invoking git from the compiler, as it can be a vector
for unwanted behavior. I would agree with that assessment, so I am
trying to settle on a mechanism where I can parse git state myself
(on a best-effort basis; this is only for diagnostics, so fully
featured support for all environments is not necessary).

quoted

 - is there already a better way to identify if the rebase was triggered by
   `git rebase` or `git pull` (configured to rebase)?

I haven't studied the internals on this yet, but I think the common
pattern is to look at REBASE_HEAD vs. MERGE_HEAD.

Thank you for the additional information! That prompted me to look
into the rest of the files once more, which gave me some hacky ideas
on how to get the data I want, and this indeed seems to be
sufficient to differentiate these two.

quoted

 - if neither of the above has a "yes" answer, would git consider *adding*
   that information, both for third-parties as well as to extend its own UI?

I think "git status" already shows some of this (maybe not the
branches in question, but certainly the "it looks like you're in the
middle of a rebase/merge/cherry-pick/etc.").

I looked around again and arrived to the following conclusions:

 - presence of .git/rebase-merge (and its files) is enough to
   differentiate between a rebase and a merge
 - .git/rebase-merge/head-name is enough to identify one of the sections
 - identifying *at least* one of the sections is enough to make the
   output clear enough (even if ideally you'd identify both)
 - the sha in FETCH_HEAD matching .git/rebase-merge/onto is enough
   to identify that we're dealing with a `git rebase --rebase`
 - there's information that is only present in MERGE_MSG in
   free-form text, that isn't present anywhere else
 - I can extract the "missing" information for either the
   identifying information of where we are merging, be it because of
   a `git pull --no-rebase` or `git merge`; the only issue I see is
   in having to rely that the output will not change from either of
   "Merge branch 'main' into branch-name" and
   "Merge branch 'main' of example.url:user/repo" (how much trouble
   am I inviting if I were to try and rely on this text not changing
   so that I can get 'main' and the remote url from here?)

With this, I'm successfully able to identify at least one of the
sections in the patches in all cases, which is "good enough" for my
use-case, and with some hacks I can identify both for all but the
`git rebase` case, without having to invoke git.

Beyond hearing from any warnings about me relying on the textual
format of MERGE_MSG or mistakes on the assumptions laid above, I
would like to suggest two changes to git that I think would be
beneficial to devs and users.

First, the information present in MERGE_MSG should be available in a
more structured format, to allow for tools to deal with git state in
a less coupled way. (This might not be worth it, and the textual
representation is already "stable enough" to rely on.)

Secondly, and perhaps more importantly, when generating the diff
markers that end up in the user files, their description includes
only the full sha or HEAD, or the short-sha and the commit message.
I would propose that the branch be identified as well in the
generated code.  This could look something like:

`git rebase`:
<<<<<<< HEAD [branch 'main']
=======

quoted

quoted

quoted

quoted

quoted

quoted

e644375 (commit message) [branch 'name']

`git merge`:
<<<<<<< HEAD [branch 'name']
=======
------- between this marker and `>>>>>>>` is the code from branch 'master'
    println!("Hello, main!");

quoted

quoted

quoted

quoted

quoted

quoted

[branch 'main']

`git pull --rebase`:
<<<<<<< HEAD [local branch 'main']
=======

quoted

quoted

quoted

quoted

quoted

quoted

8191e7e4f9f82be45bdd4e71c37d2adcf4f88aa2 [branch 'main' of example.tld:user/repo]

`git pull --no-rebase`:
<<<<<<< HEAD [branch 'main' of example.tld:user/repo]
=======

quoted

quoted

quoted

quoted

quoted

quoted

ebbeec7 (commit message) [local branch 'main']

The format doesn't have to match the above exactly, but having the
commit *and branch* information will make it much easier for people
to identify things at a glance, at the cost of some additional
verbosity in the generated code.

The source of the issue is that where "our" and "their" code is in
the patch depends on a somewhat "arbitrary" distinction (as far as
a non-implementer is concerned) and it *swaps places* depending on
whether we are rebasing or merging. Adding some context to the
resulting patches would go a long way of mitigating the confusion
this causes.

Happy holidays,
Esteban Küber