1. 39
  1.  

  2. 8

    I really love this article, it sheds light on a topic that was opaque to me.

    Having said that, it still leaves some things unclear to me.

    If I’m reading it right, the recommendation for shall changes is:

    If the default Myers doesn’t product optimally readable diffs, try patience. If that still isn’t good, use histogram.

    In practice, I don’t want to be trying out three different algorithms and carefully eyeballing the results. Why not just use histogram all the time when human readability matters? Are there cases where histogram is less readable than the other two?

    1. 6

      So, “histogram” for code review, standard diff is fine for pretty much anything else.

      1. 6

        I just use histogram always, set via global configuration. I haven’t spotted yet a place where it would be better to use another one.

        1. 2

          I guess if you’re submitting diffs by email you might as well uses the fastest reasonable algorithm. But the vast majority of people don’t do that - really it sounds like histogram ought to be the default.

          1. 8

            When you submit via email then that is the format that will be used for review as well, so I think that histogram would be the best there as well.

            1. 1

              True enough. I guess all the machine readable communication is done though binary deltas.

      2. 1

        I use histogram, but I keep wishing for a byte level diff algorithm. Not primarily for human consumption, but for rebase to see changes for what they are instead of creating pointless conflicts. It would save me an hour every week.

        That would also fix the problem of indentation changes. Yes, there is –ignore-all-space, but no, it doesn’t display indentation changes for what they are. Besides that the shown indentation level is wrong, which is significant for python.