Repository files navigation

Riff is a wrapper arounddiff that highlights which parts of lines have changed.

Unchanged parts of changed lines are shown in yellow.

riff alsohelpfully highlights conflicts and merge commits.

Much likegit, Riff sends its output to a pager, trying these in order:

1. Whatever is specified in the$PAGER environment variable
2. moar because it is nice
3. less because it is ubiquitous

git diff | riff

Or if you do...

git config --global pager.diff riffgit config --global pager.show riffgit config --global pager.log riffgit config --global interactive.diffFilter "riff --color=on"

... then all futuregit diff,git show andgit log --patch output will berefined.

Or you can useriff as an alias fordiff:

riff file1.txt file2.txt

You can configureriff by setting theRIFF environment variable to one ormore (space separated) command line options.

For example, setRIFF=--no-adds-only-special to disable adds-only specialhighlighting.

brew install riff

paru -S riffdiff

cargo install riffdiff

1. Gohere and download thecorrect binary for your platform

   • If no binary exists for your platform, pleasereportit

2. chmod a+x riff-*

3. mv riff-* /usr/local/bin/riff

4. Optionally followed by this to have riff highlightgit output by default:

git config --global pager.diff riffgit config --global pager.show riffgit config --global pager.log riffgit config --global interactive.diffFilter "riff --color=on"

This VSCode extension for improved Git commit messageeditingis nice. Yes, I wrote it and I'm tooting my own horn here.

Good choice if you (like me!) areusing VSCode for Git commit messageediting.

riff can highlight conflict markers created bygit:

riff highlighting agit merge commits highlighting

If you put example input and output in thetestdata directory, thencargo test will verify that they match.

On mismatches, you can runtestdata-examples.sh to compare current output tothe expected output for all examples, and optionally update expectations.

Invokeci.sh to run the same thing as CI.

Invokebenchmark.py to get numbers for how fast your current source code isversus earlier releases.

Invokegit log -p | cargo run -- to demo highlighting.

Just invoke./release.sh and follow instructions.

If you want to test the release script without actually releasing anything, do:

./release.sh --dry

• Render ESC characters in the diff as Unicode ␛
• --help: Only print installing-into-$PATH help if we aren't already beingexecuted from inside of the$PATH
• Add test for never changing the number of lines in the input, thatmesses upgit add -p behavior.
• Make sure we highlight the output ofgit show --stat properly
• Given three files on the command line, we should pass them and anyoptions on todiff3 and highlight the result

• Detect moved blocks and use a number as a prefix for both the addand the remove part of the move. Highlight any changes just likefor other changes.

• Make a main program that can read input from stdin and print it tostdout.
• Make the main program identify different kinds of lines by prefixand color them accordingly. Use the same color scheme asgit.
• Make the main program identify blocks of lines that have beenreplaced by another block of lines.
• Make the Refiner not highlight anything if either old or new isempty
• Usehttps://crates.io/crates/diffus to refine hunks
• Build refined hunks and print them
• Highlight^diff,^index,^+++ and^--- lines in bold white
• Prefix all added / removed lines with the correct ANSI color code
• Don't highlight the initial+ /- on added / removed lines
• Make sure we get the linefeeds right in diffs, trygit show 28e074bd0fc246d1caa3738432806a94f6773185 with and withoutriff.
• Visualize added line endings
• Visualize removed line endings
• Visualize removed linefeed at end of file properly
• Visualize adding a missing linefeed at end of file properly
• Visualize missing linefeed at end of file as part of the contextproperly
• Refineax->bx\nc properly
• Strip all color from the input before handling it to enable users toset Git's pager.diff and pager.show variables to 'riff' without alsoneeding to set color.diff=false.
• If stdout is a terminal, pipe the output to a pager using thealgorithm described undercore.pager ingit help config.
• You can dogit diff | riff and get reasonable output.
• Do not highlight anything if there are "too many" differences between thesections. The point here is that we want to highlight changes, but if it's areplacement rather than a change then we don't want to highlight it.
• Refine by word rather than by character
  • Test casegit show 2ac5b06: Should highlight all of bothsome andone or.
• Do some effort to prevent fork loops if people set$PAGER toriff
• Add support for--help
• Add support for--version
• Print help and bail if stdin is a terminal
• On exceptions, print the current version just like--version
• On exceptions, print a link to the issue tracker
• Add test case verifying that theInspired by part ofgit show 77c8f77 -- bin/riff is highlighted as an upside down L.
• Find out how the LCS algorithm scales and improve the heuristic forwhen not to call it.
• Tune the upper bound on how large regions we should attempt to refine
• Make a CI script
• Set up CI calling the CI script
• Documentci.sh's existence
• Figure out cross compiling to Linux and macOS ARM (look intocross whichuses Docker for cross compiling)
• Make a release script
• Documentrelease.sh's existence
• Verify that the Linux binary works
• Document install instructions
• Make a public release
• Remedyrelease.sh FIXMEs
• Add a trailing whitespace analysis pass to the Refiner
• Let the Refiner highlight whitespace errors among the added lines inreverse red.
• Highlight whitespace in added parts only
• Add highlighting of non-leading tabs to the whitespace analysis
• Profile and see if we can go faster
• Inci.sh, add a test case verifying that our exception handler printsbacktraces in release builds (should fail when stripping the release binary)
• Inci.sh, add a test case verifying that our exception handler prints linenumbers for theriff frames in the backtraces, in release builds. Thisshould fail when stripping the release binary.
• Require line numbers in backtraces in release builds
• Make the Linux binary smaller
• Put argv contents in crash report
• Handle plain non-git diff files
• Given two files on the command line, we should pass them on todiff andhighlight the result.
• Supportriff -b path1 path2 to diff files ignoring whitespace
• Bound how-much-to-highlight restriction by number of characters highlightedrather than by number of tokens highlighted
• Get ourselves some kind of benchmark suite / example(s)
• Dogit show 5e0a1b2b13528f40299e78e3bfa590d9f96637af and scroll to the end.How should we visualize the reformatting of the No-newline-at-eof code?
• Dogit show 0f5dd84 and think about how to visualize one linechanging to itself with a comma at the end plus a bunch of entirelynew lines. Think of a constant array getting one or more extramembers.
• Dogit show -b 77c8f77 and think about what rule we should use tohighlight the leading spaces of the+ refined and+ page linesat the end of the file.
• Dogit show 57f27da and think about what rule we should use to getthe REVERSE vs reversed() lines highlighted.
• Think about how to visualize an added line break together with someindentation on the following line.
• Make sure we can handle agit conflictresolution diff. File format is described athttp://git-scm.com/docs/git-diff#_combined_diff_format.