On Thu, Feb 09 2023, Elijah Newren wrote:
> [...] I
> think "myers" is default for historical reasons and histogram is
> better not just for special Salesforce xml files, but code files too.
> The output makes more sense to users. So much so that even though my
> simple testing suggested it had a 2% performance penalty compared to
> myers, I forced ort to use it[1] even though I designed everything
> else in that algorithm around eking out maximum performance. Others
> who have tested the diff algorithms have also found histogram has very
> similar performance to myers, and oftentimes even beats it[2][3].
> Also, worries about invalidating rerere caches[4] was real, but we
> already paid that price when we switched to ort.
FWIW as someone who went through that one-time pain for my many git.git
topics it wasn't even a price, it was paying me!
Maybe it's just confirmation bias, or looking at the conflicts with
fresh eyes, but I found I mis-solved some of them seemingly because the
output from the old conflicts was so confusing, but much better with
"ort".
> And if performance
> is still a worry, [3] gives me reason to believe we can make our
> histogram implementation faster. Finally, for the period of time when
> Palantir was letting me make an internal git distribution (mostly for
> testing ort), I also carried a patch that changed the default diff
> algorithm to histogram (not just for ort, but for diff/log/etc. as
> well). Never had any complaints from the users from it. Perhaps you
> could do the same in your local version of git used by gitaly?
I think that might be worth considering for GitLab, John? Although the
bias has definitely been to go with vanilla git semantics, but it sounds
like you might be in favor of endorsing a patch to change the default,
so if that happens to solve the problem...
> I also think the user request got converted to a particular
> solution without looking at the wider problem space: The idea seemed
> to assume "myers" is default for a good reason, and thus asked for an
> option to use something else. I'm not sure the assumption is valid;
Just on the "wider problem", I've also looked at a lot of "bad diffs"
and there's interesting cases where histogram does equally bad as the
others *from most user's POV*, but from a "let's make a small diff" for
a computer it's perfect.
I've seen this most commonly with repetative file formats, e.g JSON-like
ones are a good example. You've probably looked at this exact thing N
times, but in case it's useful consider:
$ cat a
{
thing => 'foo',
a => 'b',
},
{
c => 'd',
thing => 'bar',
}
$ cat b
{
thing => 'foo',
a => 'b',
},
{
c => 'd',
},
{
e => 'f',
thing => 'bar',
}
Here all of our diff algorithms generate this equally terrible diff, or
a great diff, depending on your POV :):
diff --git a/a b/b
index 186017c1f38..5afadde1800 100644
--- a/a
+++ b/b
@@ -4,5 +4,8 @@
},
{
c => 'd',
+},
+{
+ e => 'f',
thing => 'bar',
}
The problem here is that from the user's POV they didn't add a closing
bracket, comma, open bracket etc. They added a whole new copy/pasted
block, and then modified a key-value in the subsequent one.
But the diff engine doesn't know about any of that, and will "helpfully"
proceed to "steal" parts of the previous block.
All of the cases where users have asked me (in person) about some bad
diffs have pretty much come down to this sort of thing.
In those cases one of the algorithms sometimes *happened* to find a
"better" diff, but in my experience it's been a
wrong-clock-is-right-twice-a-day sort of thing.
I've wondered if we couldn't have some much more stupid but effective
solution to these common cases. All of the ones I remember could
basically be expressed as a hypothetical:
[diff "c"]
balanceBrackets = true
Where we'd try as hard as we could not to produce diffs that had
un-balanced brackets. I.e. in this case (I manually produced this by
converting the brackets[1] to []'s, then changing them back:
diff --git a/a b/b
index 186017c1f38..05cdd03bfa4 100644
--- a/a
+++ b/b
@@ -2,7 +2,10 @@
thing => 'foo',
a => 'b',
},
+{
+ x => 'y',
+},
{
- c => 'd',
+ c => 'f',
thing => 'bar',
}
That's a much worse diff to a computer (now 11 lines, v.s. 8 lines
before), but I'd think to most users that's *much* more understandable,
just by knowing just a bit about the language (although I'd argue we
could go as far as assuming this in general, with how common balanced
brackets[1] are across languages).
P.S.: Funny story: at <pastjob> I once helped a user who'd been
struggling for hours to turn their already working change into
something that made more sense with "git diff".
We eventually managed to come up with something that looked
"right", I can't remember how, probably some mixture of -U<n>,
diff algorithm etc.
Their next question was "Ok, so how do I commit this?", referring
to "this particular version of the diff".
Which, having already spent more time than I'd like to admit in
trying to "help" them was a good reminder to first ask what
problem we're trying to solve :)
1. By "balanced bracket" I'm referring not just to "{}", but what's
considered a "mirrored" character in Unicode. I.e. not just ()[]{}<>
etc., but also ∈∋ and the like (see
e.g. https://www.compart.com/en/unicode/U+2208)
For better or worse the Perl 6 language has this as part of its
grammar, see e.g.:
https://andrewshitov.com/2018/01/23/embedded-comment-delimiters-in-perl-6/
