Fossil Forum

`fossil diff`: 3 failure cases
Login

`fossil diff`: 3 failure cases

Chronological

`fossil diff`: 3 failure cases

(1) By Florian Balmer (florian.balmer) on 2022-02-18 05:57:03 [source]

I've seen 3 failures with fossil diff, introduced by check-in [1cb182ac18]. I've created a minimal repository containing just the (otherwise independent) test cases, it's attached to a new message in the Fossil developer chat. (The test cases are part of my set of private Fossil patches, so nothing confidential, but also nothing released to the public, so far.)

Steps to reproduce:

  • Open the minimal test case repository
  • Run fossil diff --checkin tip

Observed results:

  • The generated diff output is not identical for Fossil versions including or omitting the mentioned check-in [1cb182ac18].

A note why I found these problems:

I keep my 30+ private Fossil patches in thematically grouped old-school plain-text patch files, with a scripting ecosystem to apply them in a series, to rebase them to another Fossil version (minus the usual manual resolving of merge conflicts), and to regenerate them. This allows me to manage functional groups of code changes and comments (at the top of each patch file). Lumping together all my patches into one single branch, or in 30+ separate branches, seems too confusing to me.

(2) By Florian Balmer (florian.balmer) on 2022-02-18 07:55:01 in reply to 1 [link] [source]

Wait a moment ... maybe it's a false alarm, and the differences are due to the fact that the order of output for some inserted and deleted blocks is reversed with [1cb182ac18].

I need some time to verify this in detail. Also, the differences in Side-By-Side Web UI view are very confusing.

BTW, I'm using Fossil all the time, and love branching and merging to develop new features. But it's funny that for 30+ custom patches, a pile-of-file approach seems easier to me, as I can quickly enable and disable individual patches, for example -- much faster than backing-out the affected branch(es) each time, and much much faster than undoing individual changes in a single lumped patch branch. So I basically reinvented the problem that Fossil was trying to solve ;-)

(3) By Florian Balmer (florian.balmer) on 2022-02-18 11:37:01 in reply to 2 [link] [source]

Yes, I can confirm it's a false alert.

Redirecting output of fossil diff to disk yields two different patch files, depending whether or not the mentioned check-in is active, but re-applying them with the patch utility yields zero net change.

And when copying the web UI output for side-by-side and unified diffs to a text editor and sort it before comparison, the results are identical -- except that the diff produced with the mentioned check-in active has less white space noise, which was the whole point!

Not sure whether the method described by the last paragraph is sufficient to prove diff equality, but overall, I'm pretty confident I was just fooled by reordered output blocks.

Sorry for the noise. And thanks for Fossil, as always!