git/list[1] front-page[2] threads[3] people[4] search[5] about
 

Re: Merge commit diff results are confusing and inconsistent

From
Philip Oakley <philipoakley@iee.org>
Date
May 11, 2019, 14:08 UTC
Message-ID
<7cfb151e-346a-0eb5-aaa9-0a3e1da0fb2a@iee.org>
In-Reply-To
<CAHd499BkdpsA2BdB0Hsv3xXzpMyMzW8CSuYf2gQX0Jf7OoYBGw@mail.gmail.com>
Hi Robert,
On 07/05/2019 15:10, Robert Dailey wrote:
Show 10 quoted lines
> The majority use case I'm interested in is seeing net-positive changes
> that happen in merge commits. Normally I take for granted that merge
> commits have nothing meaningful in them (meaningful here defined as
> something unexpected for a merge commit). But what if someone makes a
> poor decision and does some crazy refactoring in 1 file and amends it
> into a merge commit? Let's also say that these changes are done to a
> file that wasn't modified in any parent (say a unrelated.txt next to
> your color.txt). Since neither parent cares about that file for the
> purposes of the merge, I am trying to make sense of a revision
> specification that can be used to see what they did to that file.
I see that you are specifically interested in seeing 'net-positive' changes.

Part of the problem is that for a merge commit there are multiple choices as to the implied initial central merge, where A and B are combined to create X [which I just called the central merge], to which further changes are made to create the final merge commit C. (Note: X is never committed, and is somewhat 'mythical')

These cases where there needs to be 'further changes', either to resolve conflicts because we never got a cleanly merged X, or the user added changes, we an "Evil Commit/Merge". Definitions vary slightly between different protagonists in the VCS world as to the best evil merge resolution starategies.

For your 'net-positive' changes, what is needed is to effectively generate that mythical clean initial merge X where either we delete from both sides, or we have a simple addition only from one side (addition/deletion normally being of whole lines). It is only that way that allows the changes from X to C to be addition only.

Unfortunately there is currently no diff representation that does that, as there is no method of indicating that middle X state. In the worst case there are always pathological cases.

A similar problem exists for the “reuse recorded resolution” (rerere / redo) storage of conflict resolutions. At present there isn't a way of exchanging such resolutions in a mechanism similar to a diff. In fact I was only just asking about that [1]  within the last two days! There is some discussion about the rerere database in [2], should you want a look. -- Philip

[1] rerere - https://public-inbox.org/git/b8e56556-6c83-9e37-38e9-ac67f51b5cd2@iee.org/ [2] https://github.com/git/git/blob/master/Documentation/technical/rerere.txt

Previous: Elijah Newren
Message 12 of 12 in “Merge commit diff results are confusing and inconsistent”
  1. Robert DaileyMay 3, 2019
  2. Eckhard MaaßMay 3, 2019
  3. Robert DaileyMay 6, 2019
  4. Eckhard MaaßMay 6, 2019
  5. Ævar Arnfjörð BjarmasonMay 6, 2019
  6. Robert DaileyMay 7, 2019
  7. Robert DaileyMay 7, 2019
  8. Denton LiuMay 7, 2019
  9. Eckhard MaaßMay 7, 2019
  10. Ævar Arnfjörð BjarmasonMay 7, 2019
  11. Elijah NewrenMay 7, 2019
  12. Philip OakleyMay 11, 2019

Read the whole thread, see it on lore, or plain text.

$ cat FOOTERMessages come from the public archive at lore.kernel.org/git, fetched every hour. The front page is chosen and written each morning by an AI editor and can be wrong; the threads themselves are the record. About and API. For agents: an MCP server at https://gitlist.dev/mcp, and any thread, story or person page as Markdown by adding .md to its URL (or sending Accept: text/markdown). Details in /llms.txt.