conflicts: prefer emitting snapshot for first side

[scott2000]

Often, the diffs for the first side and second side are approximately the same size, so we have the choice of whether we want to emit a snapshot for the first side or for the second side. Currently, we prefer to emit a diff for the first side when possible.

I think it would make more sense to prefer emitting snapshots instead for the first side since the first side of the merge usually makes more sense semantically as the snapshot. For instance, in merges, the first side is the first parent, and in rebases, the first side is the destination to which the diff is being applied. Therefore, I think we should prefer to emit a snapshot for the first term unless it would create a diff that's more than 10% larger.

Stacked on #7872

Checklist

If applicable:

• I have updated CHANGELOG.md
• I have updated the documentation (README.md, docs/, demos/)
• I have updated the config schema (cli/src/config-schema.json)
• I have added/updated tests to cover my changes

[joyously]

Did you mistype something?

Currently, we prefer to emit a diff for the first side when possible.
I think it would make more sense to prefer emitting snapshots for the first side

Edit: reading it again, I guess you are saying diff instead of snapshot, when before all I saw was first instead of first.

[scott2000]

Edit: reading it again, I guess you are saying diff instead of snapshot, when before all I saw was first instead of first.

Yes, that is what I intended. I updated the description to be hopefully a bit clearer.

[martinvonz]

FWIW, I'm not attached to the idea of even trying to pick the smaller diff. Would it be even better in your mind if we always picked the first side as the snapshot? It would at least remove the confusion that I sometimes hear about why the markers are/appear inconsistent.

[scott2000]

FWIW, I'm not attached to the idea of even trying to pick the smaller diff. Would it be even better in your mind if we always picked the first side as the snapshot? It would at least remove the confusion that I sometimes hear about why the markers are/appear inconsistent.

I personally do like that it at least sometimes picks the second side as the snapshot, but it only would matter to me in extreme cases. Like if I made a large change to a file, but then I rebased it onto trunk where someone made a small change (e.g. fixing a typo), it's nice for me to be able to see the diff of the typo instead of having to re-apply the whole diff for my large change. But maybe I'm just used to the current implementation so the inconsistency doesn't really bother me :)

If we do decide to go with a similar approach to what I proposed in this PR, I would also be open to other factors instead of 10% larger. For instance, preferring the first side unless it would make the diff more than twice as large (which is presumably more rare). I was initially thinking it's safer to make a small adjustment, since a larger change might annoy more people, but now I'm thinking maybe 10% is too small of a change that it wouldn't even be worth making.

For some context, I'm mainly thinking about this in relation to what I was experimenting with in #7692, because some conflict labels (e.g. for squashed commits) are easier to understand with the first side as the snapshot. I was trying to come up with readable examples, but it was always rendering the diff first since I was using the labels "left", "base", and "right" for the sides, so I was thinking it would be good to have a bias towards snapshot first, instead of the old implementation which actually has a bias towards diffs first.

[scott2000]

I think #7917 would probably be a better option than this so I'm closing this PR in favor of that issue