Merge branch 'jk/git-tricks'
* jk/git-tricks: completion: match ctags symbol names in grep patterns contrib: add git-jump script contrib: add diff highlight script
This commit is contained in:
Junio C Hamano
commit
324bc2a7ee
@ -1430,6 +1430,10 @@ _git_gitk ()
|
||||
_gitk
|
||||
}
|
||||
|
||||
__git_match_ctag() {
|
||||
awk "/^${1////\\/}/ { print \$1 }" "$2"
|
||||
}
|
||||
|
||||
_git_grep ()
|
||||
{
|
||||
__git_has_doubledash && return
|
||||
@ -1452,6 +1456,15 @@ _git_grep ()
|
||||
;;
|
||||
esac
|
||||
|
||||
case "$cword,$prev" in
|
||||
2,*|*,-*)
|
||||
if test -r tags; then
|
||||
__gitcomp "$(__git_match_ctag "$cur" tags)"
|
||||
return
|
||||
fi
|
||||
;;
|
||||
esac
|
||||
|
||||
__gitcomp "$(__git_refs)"
|
||||
}
|
||||
|
||||
|
||||
57
contrib/diff-highlight/README
Normal file
57
contrib/diff-highlight/README
Normal file
@ -0,0 +1,57 @@
|
||||
diff-highlight
|
||||
==============
|
||||
|
||||
Line oriented diffs are great for reviewing code, because for most
|
||||
hunks, you want to see the old and the new segments of code next to each
|
||||
other. Sometimes, though, when an old line and a new line are very
|
||||
similar, it's hard to immediately see the difference.
|
||||
|
||||
You can use "--color-words" to highlight only the changed portions of
|
||||
lines. However, this can often be hard to read for code, as it loses
|
||||
the line structure, and you end up with oddly formatted bits.
|
||||
|
||||
Instead, this script post-processes the line-oriented diff, finds pairs
|
||||
of lines, and highlights the differing segments. It's currently very
|
||||
simple and stupid about doing these tasks. In particular:
|
||||
|
||||
1. It will only highlight a pair of lines if they are the only two
|
||||
lines in a hunk. It could instead try to match up "before" and
|
||||
"after" lines for a given hunk into pairs of similar lines.
|
||||
However, this may end up visually distracting, as the paired
|
||||
lines would have other highlighted lines in between them. And in
|
||||
practice, the lines which most need attention called to their
|
||||
small, hard-to-see changes are touching only a single line.
|
||||
|
||||
2. It will find the common prefix and suffix of two lines, and
|
||||
consider everything in the middle to be "different". It could
|
||||
instead do a real diff of the characters between the two lines and
|
||||
find common subsequences. However, the point of the highlight is to
|
||||
call attention to a certain area. Even if some small subset of the
|
||||
highlighted area actually didn't change, that's OK. In practice it
|
||||
ends up being more readable to just have a single blob on the line
|
||||
showing the interesting bit.
|
||||
|
||||
The goal of the script is therefore not to be exact about highlighting
|
||||
changes, but to call attention to areas of interest without being
|
||||
visually distracting. Non-diff lines and existing diff coloration is
|
||||
preserved; the intent is that the output should look exactly the same as
|
||||
the input, except for the occasional highlight.
|
||||
|
||||
Use
|
||||
---
|
||||
|
||||
You can try out the diff-highlight program with:
|
||||
|
||||
---------------------------------------------
|
||||
git log -p --color | /path/to/diff-highlight
|
||||
---------------------------------------------
|
||||
|
||||
If you want to use it all the time, drop it in your $PATH and put the
|
||||
following in your git configuration:
|
||||
|
||||
---------------------------------------------
|
||||
[pager]
|
||||
log = diff-highlight | less
|
||||
show = diff-highlight | less
|
||||
diff = diff-highlight | less
|
||||
---------------------------------------------
|
||||
124
contrib/diff-highlight/diff-highlight
Executable file
124
contrib/diff-highlight/diff-highlight
Executable file
@ -0,0 +1,124 @@
|
||||
#!/usr/bin/perl
|
||||
|
||||
# Highlight by reversing foreground and background. You could do
|
||||
# other things like bold or underline if you prefer.
|
||||
my $HIGHLIGHT = "\x1b[7m";
|
||||
my $UNHIGHLIGHT = "\x1b[27m";
|
||||
my $COLOR = qr/\x1b\[[0-9;]*m/;
|
||||
|
||||
my @window;
|
||||
|
||||
while (<>) {
|
||||
# We highlight only single-line changes, so we need
|
||||
# a 4-line window to make a decision on whether
|
||||
# to highlight.
|
||||
push @window, $_;
|
||||
next if @window < 4;
|
||||
if ($window[0] =~ /^$COLOR*(\@| )/ &&
|
||||
$window[1] =~ /^$COLOR*-/ &&
|
||||
$window[2] =~ /^$COLOR*\+/ &&
|
||||
$window[3] !~ /^$COLOR*\+/) {
|
||||
print shift @window;
|
||||
show_pair(shift @window, shift @window);
|
||||
}
|
||||
else {
|
||||
print shift @window;
|
||||
}
|
||||
|
||||
# Most of the time there is enough output to keep things streaming,
|
||||
# but for something like "git log -Sfoo", you can get one early
|
||||
# commit and then many seconds of nothing. We want to show
|
||||
# that one commit as soon as possible.
|
||||
#
|
||||
# Since we can receive arbitrary input, there's no optimal
|
||||
# place to flush. Flushing on a blank line is a heuristic that
|
||||
# happens to match git-log output.
|
||||
if (!length) {
|
||||
local $| = 1;
|
||||
}
|
||||
}
|
||||
|
||||
# Special case a single-line hunk at the end of file.
|
||||
if (@window == 3 &&
|
||||
$window[0] =~ /^$COLOR*(\@| )/ &&
|
||||
$window[1] =~ /^$COLOR*-/ &&
|
||||
$window[2] =~ /^$COLOR*\+/) {
|
||||
print shift @window;
|
||||
show_pair(shift @window, shift @window);
|
||||
}
|
||||
|
||||
# And then flush any remaining lines.
|
||||
while (@window) {
|
||||
print shift @window;
|
||||
}
|
||||
|
||||
exit 0;
|
||||
|
||||
sub show_pair {
|
||||
my @a = split_line(shift);
|
||||
my @b = split_line(shift);
|
||||
|
||||
# Find common prefix, taking care to skip any ansi
|
||||
# color codes.
|
||||
my $seen_plusminus;
|
||||
my ($pa, $pb) = (0, 0);
|
||||
while ($pa < @a && $pb < @b) {
|
||||
if ($a[$pa] =~ /$COLOR/) {
|
||||
$pa++;
|
||||
}
|
||||
elsif ($b[$pb] =~ /$COLOR/) {
|
||||
$pb++;
|
||||
}
|
||||
elsif ($a[$pa] eq $b[$pb]) {
|
||||
$pa++;
|
||||
$pb++;
|
||||
}
|
||||
elsif (!$seen_plusminus && $a[$pa] eq '-' && $b[$pb] eq '+') {
|
||||
$seen_plusminus = 1;
|
||||
$pa++;
|
||||
$pb++;
|
||||
}
|
||||
else {
|
||||
last;
|
||||
}
|
||||
}
|
||||
|
||||
# Find common suffix, ignoring colors.
|
||||
my ($sa, $sb) = ($#a, $#b);
|
||||
while ($sa >= $pa && $sb >= $pb) {
|
||||
if ($a[$sa] =~ /$COLOR/) {
|
||||
$sa--;
|
||||
}
|
||||
elsif ($b[$sb] =~ /$COLOR/) {
|
||||
$sb--;
|
||||
}
|
||||
elsif ($a[$sa] eq $b[$sb]) {
|
||||
$sa--;
|
||||
$sb--;
|
||||
}
|
||||
else {
|
||||
last;
|
||||
}
|
||||
}
|
||||
|
||||
print highlight(\@a, $pa, $sa);
|
||||
print highlight(\@b, $pb, $sb);
|
||||
}
|
||||
|
||||
sub split_line {
|
||||
local $_ = shift;
|
||||
return map { /$COLOR/ ? $_ : (split //) }
|
||||
split /($COLOR*)/;
|
||||
}
|
||||
|
||||
sub highlight {
|
||||
my ($line, $prefix, $suffix) = @_;
|
||||
|
||||
return join('',
|
||||
@{$line}[0..($prefix-1)],
|
||||
$HIGHLIGHT,
|
||||
@{$line}[$prefix..$suffix],
|
||||
$UNHIGHLIGHT,
|
||||
@{$line}[($suffix+1)..$#$line]
|
||||
);
|
||||
}
|
||||
92
contrib/git-jump/README
Normal file
92
contrib/git-jump/README
Normal file
@ -0,0 +1,92 @@
|
||||
git-jump
|
||||
========
|
||||
|
||||
Git-jump is a script for helping you jump to "interesting" parts of your
|
||||
project in your editor. It works by outputting a set of interesting
|
||||
spots in the "quickfix" format, which editors like vim can use as a
|
||||
queue of places to visit (this feature is usually used to jump to errors
|
||||
produced by a compiler). For example, given a diff like this:
|
||||
|
||||
------------------------------------
|
||||
diff --git a/foo.c b/foo.c
|
||||
index a655540..5a59044 100644
|
||||
--- a/foo.c
|
||||
+++ b/foo.c
|
||||
@@ -1,3 +1,3 @@
|
||||
int main(void) {
|
||||
- printf("hello word!\n");
|
||||
+ printf("hello world!\n");
|
||||
}
|
||||
-----------------------------------
|
||||
|
||||
git-jump will feed this to the editor:
|
||||
|
||||
-----------------------------------
|
||||
foo.c:2: printf("hello word!\n");
|
||||
-----------------------------------
|
||||
|
||||
Obviously this trivial case isn't that interesting; you could just open
|
||||
`foo.c` yourself. But when you have many changes scattered across a
|
||||
project, you can use the editor's support to "jump" from point to point.
|
||||
|
||||
Git-jump can generate three types of interesting lists:
|
||||
|
||||
1. The beginning of any diff hunks.
|
||||
|
||||
2. The beginning of any merge conflict markers.
|
||||
|
||||
3. Any grep matches.
|
||||
|
||||
|
||||
Using git-jump
|
||||
--------------
|
||||
|
||||
To use it, just drop git-jump in your PATH, and then invoke it like
|
||||
this:
|
||||
|
||||
--------------------------------------------------
|
||||
# jump to changes not yet staged for commit
|
||||
git jump diff
|
||||
|
||||
# jump to changes that are staged for commit; you can give
|
||||
# arbitrary diff options
|
||||
git jump diff --cached
|
||||
|
||||
# jump to merge conflicts
|
||||
git jump merge
|
||||
|
||||
# jump to all instances of foo_bar
|
||||
git jump grep foo_bar
|
||||
|
||||
# same as above, but case-insensitive; you can give
|
||||
# arbitrary grep options
|
||||
git jump grep -i foo_bar
|
||||
--------------------------------------------------
|
||||
|
||||
|
||||
Related Programs
|
||||
----------------
|
||||
|
||||
You can accomplish some of the same things with individual tools. For
|
||||
example, you can use `git mergetool` to start vimdiff on each unmerged
|
||||
file. `git jump merge` is for the vim-wielding luddite who just wants to
|
||||
jump straight to the conflict text with no fanfare.
|
||||
|
||||
As of git v1.7.2, `git grep` knows the `--open-files-in-pager` option,
|
||||
which does something similar to `git jump grep`. However, it is limited
|
||||
to positioning the cursor to the correct line in only the first file,
|
||||
leaving you to locate subsequent hits in that file or other files using
|
||||
the editor or pager. By contrast, git-jump provides the editor with a
|
||||
complete list of files and line numbers for each match.
|
||||
|
||||
|
||||
Limitations
|
||||
-----------
|
||||
|
||||
This scripts was written and tested with vim. Given that the quickfix
|
||||
format is the same as what gcc produces, I expect emacs users have a
|
||||
similar feature for iterating through the list, but I know nothing about
|
||||
how to activate it.
|
||||
|
||||
The shell snippets to generate the quickfix lines will almost certainly
|
||||
choke on filenames with exotic characters (like newlines).
|
||||
69
contrib/git-jump/git-jump
Executable file
69
contrib/git-jump/git-jump
Executable file
@ -0,0 +1,69 @@
|
||||
#!/bin/sh
|
||||
|
||||
usage() {
|
||||
cat <<\EOF
|
||||
usage: git jump <mode> [<args>]
|
||||
|
||||
Jump to interesting elements in an editor.
|
||||
The <mode> parameter is one of:
|
||||
|
||||
diff: elements are diff hunks. Arguments are given to diff.
|
||||
|
||||
merge: elements are merge conflicts. Arguments are ignored.
|
||||
|
||||
grep: elements are grep hits. Arguments are given to grep.
|
||||
EOF
|
||||
}
|
||||
|
||||
open_editor() {
|
||||
editor=`git var GIT_EDITOR`
|
||||
eval "$editor -q \$1"
|
||||
}
|
||||
|
||||
mode_diff() {
|
||||
git diff --relative "$@" |
|
||||
perl -ne '
|
||||
if (m{^\+\+\+ b/(.*)}) { $file = $1; next }
|
||||
defined($file) or next;
|
||||
if (m/^@@ .*\+(\d+)/) { $line = $1; next }
|
||||
defined($line) or next;
|
||||
if (/^ /) { $line++; next }
|
||||
if (/^[-+]\s*(.*)/) {
|
||||
print "$file:$line: $1\n";
|
||||
$line = undef;
|
||||
}
|
||||
'
|
||||
}
|
||||
|
||||
mode_merge() {
|
||||
git ls-files -u |
|
||||
perl -pe 's/^.*?\t//' |
|
||||
sort -u |
|
||||
while IFS= read fn; do
|
||||
grep -Hn '^<<<<<<<' "$fn"
|
||||
done
|
||||
}
|
||||
|
||||
# Grep -n generates nice quickfix-looking lines by itself,
|
||||
# but let's clean up extra whitespace, so they look better if the
|
||||
# editor shows them to us in the status bar.
|
||||
mode_grep() {
|
||||
git grep -n "$@" |
|
||||
perl -pe '
|
||||
s/[ \t]+/ /g;
|
||||
s/^ *//;
|
||||
'
|
||||
}
|
||||
|
||||
if test $# -lt 1; then
|
||||
usage >&2
|
||||
exit 1
|
||||
fi
|
||||
mode=$1; shift
|
||||
|
||||
trap 'rm -f "$tmp"' 0 1 2 3 15
|
||||
tmp=`mktemp -t git-jump.XXXXXX` || exit 1
|
||||
type "mode_$mode" >/dev/null 2>&1 || { usage >&2; exit 1; }
|
||||
"mode_$mode" "$@" >"$tmp"
|
||||
test -s "$tmp" || exit 0
|
||||
open_editor "$tmp"
|
||||
Loading…
Reference in New Issue
Block a user