Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

bin/ldiff doesn't always output the correct output #6

Closed
halostatue opened this issue Aug 27, 2011 · 3 comments
Closed

bin/ldiff doesn't always output the correct output #6

halostatue opened this issue Aug 27, 2011 · 3 comments
Labels

Comments

@halostatue
Copy link
Owner

With files aX (containing aX\n) and bXaX (containing bXaX\n), the output of bin/ldiff does not match that of GNU diff.

With bin/ldiff aX bXaX:


1c1
< aX

---
> bXaX

With diff aX bXaX:

1c1
< aX

---
> bXaX

Note the extra blank lines.

The same applies with bin/ldiff -u aX bXaX:

--- aX  2011-08-27 09:36:12 -0400
+++ bXaX    2011-08-27 09:36:18 -0400

@@ -1,2 +1,2 @@
-aX
+bXaX

versus:

--- aX  2011-08-27 09:36:12.000000000 -0400
+++ bXaX    2011-08-27 09:36:18.000000000 -0400
@@ -1 +1 @@
-aX
+bXaX
@halostatue
Copy link
Owner Author

The fact that bin/ldiff -u sees the files as having two lines is likely a hint that points to the possible problem seen in Issue 2.

@halostatue
Copy link
Owner Author

This has mostly improved. The output from bin/ldiff aX bXaX:

1c1
< aX
---
> bXaX

Unified diffs are 100% better:

--- aX  2013-02-09 10:43:26.000000000 -0500
+++ bX  2013-02-09 10:43:34.000000000 -0500
@@ -1,2 +1,2 @@
-aX
+bXaX

Context diffs (not shown previously) are also correctly identical.

halostatue added a commit that referenced this issue Feb 3, 2019
Resolves #5 and #6 by adding system-output comparison calls to `bin/ldiff`
compared against some pre-generated output.
halostatue added a commit that referenced this issue Feb 4, 2019
-   Resolve ldiff output issues: Resolves #5 and #6 by adding system-output
    comparison calls to `bin/ldiff` compared against some pre-generated output.
    There is some timestamp manipulation involved with the output comparison,
    as the timestamps are unstable because of the way that git clone works.

-   Resolved a problem with bin/ldiff --context output.

-   Resolved a Numeric/Integer OptParse issue: later versions of Ruby had
    problems working with an `OptParse` option specification of `Numeric`; this
    has been changed to `Integer`.
halostatue added a commit that referenced this issue Feb 4, 2019
-   Resolve ldiff output issues: Resolves #5 and #6 by adding system-output
    comparison calls to `bin/ldiff` compared against some pre-generated output.
    There is some timestamp manipulation involved with the output comparison,
    as the timestamps are unstable because of the way that git clone works.

-   Resolved a problem with bin/ldiff --context output.

-   Resolved a Numeric/Integer OptParse issue: later versions of Ruby had
    problems working with an `OptParse` option specification of `Numeric`; this
    has been changed to `Integer`.
@halostatue
Copy link
Owner Author

The recent release of v1.4 fixes this.

halostatue added a commit that referenced this issue Jul 1, 2020
# This is the 1st commit message:

Fix improperly placed chunks

Resolve #65

- Also add even more tests for checking `ldiff` results against `diff` results.
- Fix issues with diff/ldiff output highlighted by the above tests.
- Add a parameter to indicate that the hunk being processed is the _last_ hunk;
  this results in correct counting of the hunk size.
- The misplaced chunks were happening because of an improper `.abs` on
  `#diff_size`, when the `.abs` needed to be on the finding of the maximum diff
  size.

# This is the commit message #2:

Ooops. Debugger

# This is the commit message #3:

Restore missing test

- Fix some more format issues raised by the missing test.
- Start fixing Rubocop formatting.

# This is the commit message #4:

Last RuboCop fixes

# This is the commit message #5:

Finalize diff-lcs 1.4

# This is the commit message #6:

Fix #44

The problem here was the precedence of `or` vs `||`. Switching to `||` resulted
in the expected behaviour.

# This is the commit message #7:

Resolve #43

# This is the commit message #8:

Typo

# This is the commit message #9:

Resolve #35 with a comment
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

1 participant