Re: Bug Report or Unexpected Feature when "git restore -m ." restores merge conflicted state of a file after a commit

From: Junio C Hamano <gitster@pobox.com>
Date: Apr 30, 2025, 21:39 UTC
Message-ID: <xmqqzffxz5vr.fsf@gitster.g>
In-Reply-To: <CAJt5hUyLoNfEbQe4wpES8AZP5yimos+xjqU9B4PszGxMrg50jg@mail.gmail.com>

Terry Bear <terrythebear746@gmail.com> writes:

Show 17 quoted lines

> 9. Make a merge switch
>     git switch --merge main-copy
>    The file on the "main-copy" branch should look like:
>      "update 1"
>      "<<<<<<< main-copy"
>      "======="
>      "update 2"
>      "update 3"
>      ">>>>>>> local"
> 10. Stage and commit file
>     git commit -a -m "merge conflict on main-copy"
> 11. Restore merge-conflicted state
>     git restore -m .
>
> What did you expect to happen? (Expected behavior)
> The "git restore -m ." is not supposed to restore the merge-conflicted
> state of the file after it was staged and committed

Just a quick question. If you did "git reset --hard" between steps 10 and 11, does the outcome change?

I think the behaviour you observed dates back to the very original implementation of the feature, made in cfc5789a (resolve-undo: record resolved conflicts in a new index extension section, 2009-12-25).

    resolve-undo: record resolved conflicts in a new index extension section
    
    When resolving a conflict using "git add" to create a stage #0 entry, or
    "git rm" to remove entries at higher stages, remove_index_entry_at()
    function is eventually called to remove unmerged (i.e. higher stage)
    entries from the index.  Introduce a "resolve_undo_info" structure and
    keep track of the removed cache entries, and save it in a new index
    extension section in the index_state.
    
    Operations like "read-tree -m", "merge", "checkout [-m] <branch>" and
    "reset" are signs that recorded information in the index is no longer
    necessary.  The data is removed from the index extension when operations
    start; they may leave conflicted entries in the index, and later user
    actions like "git add" will record their conflicted states afresh.

Notice that "git add" or "git commit -a" are not included in the operations that are signs that the previous conflicted state no longer needs to be recreatable? In other words, it is part of the design that you can take back the conflicted state across "git add" or "git commit", because you will thank Git later when you realize that your resolution was broken and you want to redo it after you finished your step #10.

If you do not want to restore the conflicted state, don't do "git restore -m ." at that point ;-).