Diff So Fancy: make Git diffs look good(github.com) |
Diff So Fancy: make Git diffs look good(github.com) |
imagine a for loop in which a variable (used on every line) was renamed, and buried in the loop an assignment changed slightly (eg, + became -). with a standard diff, it's really hard (for me) to pick up the minor change. with word by word diffs, it's pretty easy
(i use netbeans diff, not this tool, but they appear similar)
note: need to pipe it to "less -r"
int someOldFunction()
{
// Function body
}
+
+int newFunction()
+{
+ // New function body
+}
int someOldFunction()
{
// Function body
+}
+
+int newFunction()
+{
+ // New function body
}
The "user" in me would love a language aware diffing (and merging) system, but the developer in me is already groaning about how much work that would end up taking for arguably not that much benefit.
git diff --patience
[diff]
algorithm = patienceBut conceptually, no matter what the algorithm, the greediness is usually a requirement to maintaining the theoretical time bound of LCS based algorithms.
Patience trades the time bound for "better" results (patience is worst case O(ND^2).
Histogram is a neatly engineered and extended version of patience with an O(ND) timebound (and in fact, is faster than both myers and patience while providing good patience-like output).
At least on GitHub we have the ?w=1 URL parameter on PRs which helps a bit.
NPM?!? :)
A lot of people below are asking why a bash script (that depends on a perl script) is being recommended to install via NPM? The short reason is that NPM is the most straightforward way to get a script installed as a global binary in a cross-platform manner. This approach has worked quite well with `git-open`[0]. Asking all users to deal with the PATH is not my ideal.
In addition, I wanted a reasonable upgrade path, in case there are neccessary bugfixes. It's not a great experience if users identify bugs but the fix means they manually find it/download/PATH-ify each time. :/
That said, I'll add some Manual Install instructions to the readme so it's clear how to do this on your own. :) ( Edit: Here they are… https://github.com/stevemao/diff-so-fancy/blob/master/readme... )
Of the options out there for the above, npm - while hassle if you don't have it already installed - is probably the closest balance of maintainer and end-developer convenience.
ln -sf "$(brew --prefix)/share/git-core/contrib/diff-highlight/diff-highlight" ~/bin/diff-highlight
[pager]
log = diff-highlight | less
show = diff-highlight | less
diff = diff-highlight | lessEdit: Even the screenshot is from Paul...
Steve took the initiative to put this in it's own repo. Seems okay; I was being rather slow to ship it for real.
git diff --word-diff=color
[alias]
cdiff = diff --word-diff=colorhttps://github.com/paulirish/dotfiles/blob/master/bin/diff-s...
From the git book itself: `git config --global color.diff.meta "blue black bold"`
(In Emacs, if you're using git, magit is an amazing package. You can select a commit from the logs, dive into the diff for a file caused by that commit, highlight a region of the diff and revert the change in your working copy. It's wonderful.)
- var optionsGlassPane = new WebInspector.GlassPane(document);
For example, I shouldn't have to put up with basic colors if the terminal can do better.
Here is how it works; starting with:
#!/bin/bash
if [ -r ".svn" ] ; then
exec svn diff ${1+"$@"} | my_colorize_diff
else
git diff ${1+"$@"} | my_colorize_diff
fi
#!/usr/bin/env perl
# by Kevin Grant (kmg@mac.com)
my $term_program = (exists $ENV{'TERM_PROGRAM'} && defined $ENV{'TERM_PROGRAM'}) ? $ENV{'TERM_PROGRAM'} : '';
my $term = (exists $ENV{'TERM'} && defined $ENV{'TERM'}) ? $ENV{'TERM'} : 'vt100';
my $is_xterm = ($term =~ /xterm/);
my $is_24bit = ($term_program =~ /MacTerm/);
print "\033#3BEGIN DIFF\n";
print "\033#4BEGIN DIFF\n\033#5";
while (<>) {
if (/^\+/ && !/^\+\+/) {
if ($is_24bit) {
print "\033[48:2:150:200:150m", "\033[2K", "\033[38:2::88:m", "\033[1m";
} elsif ($is_xterm) {
print "\033[48;5;149m", "\033[2K", "\033[38;5;235m", "\033[1m";
} else {
print "\033[42m", "\033[2K", "\033[30m", "\033[1m";
}
} elsif (/^\-/ && !/^\-\-/) {
if ($is_24bit) {
print "\033[48:2:244:150:150m", "\033[2K", "\033[38:2:144:0::m";
} elsif ($is_xterm) {
print "\033[48;5;52m", "\033[2K", "\033[38;5;124m";
} else {
print "\033[41m", "\033[2K", "\033[37m";
}
} else {
print "\033[3m";
}
chomp;
print;
print "\033[0m\n";
}
print "\033#3END DIFF\n";
print "\033#4END DIFF\n\033#5";https://github.com/git/git/tree/master/contrib/diff-highligh...
For example, here's a diff where it improved readability enormously:
$ git diff --color --color-words --abbrev[0] http://www.colordiff.org/ [1] http://kdiff3.sourceforge.net/
I wonder if easing copypasting is a good or bad thing..
[diff]
tool = customvim
[difftool "customvim"]
cmd = vim -R -f -d \"$LOCAL\" \"$REMOTE\"Yeah, that helps a lot :)
I saw this, was like "cool, I want to use this", and then noted that it uses npm. I avoid installing ruby and node apps -- I have nothing against either, just that I currently don't use either language or have a dependency on a major tool written in those; but they pull in a lot of deps which take up space (at least, my experiences have been that many of these tools install way too much -- probably because I don't use either and all the "default libs" aren't on my system). On my previous machine I had lots of issues with this, so as a rule I avoid these things unless absolutely necessary. I know others who are of a similar opinion.
Fortunately I realized that it was just a shell script, and installed it directly :)
Really ? All Unix-like systems (incl OS X) can do this:
/usr/bin/install myscript.sh /usr/local/bin
It's really pretty awful as a distribution mechanism. Why not a simple Makefile?
Why whould someone who can't add $HOME/bin to $PATH be using git?
People who don't need to edit PATH might still need to track content.
Also, you seem to be assuming "xterm" supports 256 colours and everything else doesn't. The best way to figure out how many colours the terminal supports is $(tput colours). tput also looks up other useful sequences; you can "tput bold" to turn on bold mode, "tput setaf 12" to set the foreground to colour 12 (bright yellow), "tput sgr0" to zero all active formatting, etc.
- no built-in remote repos / app directory so it's just the final step of multiple install steps
- no built-in automated upgrade path
- unless you're fiddling with Cygwin or MSys2, it's not really as cross-platform
- likely to be less convenient for the maintainer than the package.json standard
Here's an idea: wouldn't it by trivial for <insert your favourite language compiler here> to expose the AST of your code, and solve this problem the easy way?
Nodejs is a programming language.
NPM is a tool to fetch libraries for node programs.
Thus NPM and Git are software development tools.
A software developer or a power user are supposed to know what $PATH or %PATH is.
Its biggest limitation on real projects is that it works on a single-file level, while all the interesting stuff happens on patch level. You may browse their forums to get an idea of what else is missing.
That said, I wish all the best to Codice and I really hope that they continue to invest in this tool.
It requires conscious work as any other dependency, but it's possible (and convenient, if you don't depend on them).
So more than probably, I'll not install npm, to test a bash wrapper to a perl script, that does something that git itself can do without external dependencies.
But obviously, different persons have different concepts of the K.I.S.S. principle.
Being a perl script... why the author didn't use CPAN? it's available in all vanilla installs of Debian, CentOS, Ubuntu, RedHat, etc...
"pip is the preferred installer program. Starting with Python 2.7.9, it is included by default with the Python binary installers."
CentOS/RHEL?
I've seen too many Python environments hosed by folks who aren't Python experts to keep suggesting that "sudo pip install <CLI tool>" is a thing most users should be doing.