[PATCH 0/3] stupid git tricks

[PATCH 0/3] stupid git tricks

[Jeff King]

Here are a few contrib tidbits that I find invaluable when working with
git. They're pretty simple ideas, but I've been using them all for
at least a year[1], and they've made my life more pleasant and
productive. So I thought I'd share.

  [1/3]: contrib: add diff highlight script
  [2/3]: contrib: add git-jump script
  [3/3]: completion: match ctags symbol names in grep patterns

-Peff

[1] Actually, they all needed significant cleanup for me not to be
    embarrassed to share them, which I just did recently. Undoubtedly I
    introduced scores of new bugs during the cleanup, so take my "at
    least a year" with a grain of salt. The _concepts_ have been proven,
    at least. :)

[PATCH 1/3] contrib: add diff highlight script

[Jeff King]

This is a simple and stupid script for highlighting
differing parts of lines in a unified diff. See the README
for a discussion of the limitations.

Signed-off-by: Jeff King <peff@peff.net>
---
I posted a similar script before, but not as a contrib patch. Many of
the comments were that this could be done more accurately inside git
itself. Undoubtedly. But this is already written, and I have found it
very useful in practice. If somebody wants to come along with an
implementation inside git-diff, I'd be happy to compare output.

 contrib/diff-highlight/README         |   57 +++++++++++++++
 contrib/diff-highlight/diff-highlight |  124 +++++++++++++++++++++++++++++++++
 2 files changed, 181 insertions(+), 0 deletions(-)
 create mode 100644 contrib/diff-highlight/README
 create mode 100755 contrib/diff-highlight/diff-highlight

diff --git a/contrib/diff-highlight/README b/contrib/diff-highlight/README
new file mode 100644
index 0000000..1b7b6df
--- /dev/null
+++ b/contrib/diff-highlight/README
@@ -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
+---------------------------------------------
diff --git a/contrib/diff-highlight/diff-highlight b/contrib/diff-highlight/diff-highlight
new file mode 100755
index 0000000..d893898
--- /dev/null
+++ b/contrib/diff-highlight/diff-highlight
@@ -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]
+	);
+}
-- 
1.7.7.rc3.37.gc4dc8

[PATCH 2/3] contrib: add git-jump script

[Jeff King]

This is a small script for helping your editor jump to
specific points of interest. See the README for details.

Signed-off-by: Jeff King <peff@peff.net>
---
 contrib/git-jump/README   |   92 +++++++++++++++++++++++++++++++++++++++++++++
 contrib/git-jump/git-jump |   68 +++++++++++++++++++++++++++++++++
 2 files changed, 160 insertions(+), 0 deletions(-)
 create mode 100644 contrib/git-jump/README
 create mode 100755 contrib/git-jump/git-jump

diff --git a/contrib/git-jump/README b/contrib/git-jump/README
new file mode 100644
index 0000000..1cebc32
--- /dev/null
+++ b/contrib/git-jump/README
@@ -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).
diff --git a/contrib/git-jump/git-jump b/contrib/git-jump/git-jump
new file mode 100755
index 0000000..13b8e9f
--- /dev/null
+++ b/contrib/git-jump/git-jump
@@ -0,0 +1,68 @@
+#!/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
+"mode_$mode" "$@" >"$tmp" || { usage >&2; exit 1; }
+test -s "$tmp" || exit 0
+open_editor "$tmp"
-- 
1.7.7.rc3.37.gc4dc8

[PATCH 3/3] completion: match ctags symbol names in grep patterns

[Jeff King]

A common thing to grep for is the name of a symbol. This
patch teaches the completion for "git grep" to look in
a 'tags' file, if present, to complete a pattern. For
example, in git.git:

  $ make tags
  $ git grep get_sha1<Tab><Tab>
  get_sha1                 get_sha1_oneline
  get_sha1_1               get_sha1_with_context
  get_sha1_basic           get_sha1_with_context_1
  get_sha1_hex             get_sha1_with_mode
  get_sha1_hex_segment     get_sha1_with_mode_1
  get_sha1_mb

Signed-off-by: Jeff King <peff@peff.net>
---
It's debatable whether this belongs in the generic completion code, as
it really only works if your project uses ctags. But I find it to be a
huge timesaver for finding callsites of functions, especially when
coupled with "git jump grep" from the previous patch.

Undoubtedly you can do something similar with cscope, or with an editor
plugin, but using grep feels very natural and simple to me.

For using with "git jump grep", I do this:

  # much easier to type
  git config --global alias.vgrep 'jump grep'

  # and set up completion for it, too
  cat >>~/.bashrc
  _git_vgrep() {
          _git_grep
  }

 contrib/completion/git-completion.bash |   11 +++++++++++
 1 files changed, 11 insertions(+), 0 deletions(-)

diff --git a/contrib/completion/git-completion.bash b/contrib/completion/git-completion.bash
index 8648a36..f4ab13d 100755
--- a/contrib/completion/git-completion.bash
+++ b/contrib/completion/git-completion.bash
@@ -1432,6 +1432,10 @@ _git_gitk ()
 	_gitk
 }
 
+_git_grep_ctag_match() {
+	awk -v ORS=' ' "/^${1////\\/}/ { print \$1 }" "$2"
+}
+
 _git_grep ()
 {
 	__git_has_doubledash && return
@@ -1454,6 +1458,13 @@ _git_grep ()
 		;;
 	esac
 
+	case "$COMP_CWORD,$prev" in
+	2,*|*,-*)
+		test -r tags || return
+		COMPREPLY=( $(compgen -W "`_git_grep_ctag_match "$cur" tags`") )
+		return
+	esac
+
 	__gitcomp "$(__git_refs)"
 }
 
-- 
1.7.7.rc3.37.gc4dc8

Re: [PATCH 3/3] completion: match ctags symbol names in grep patterns

[Junio C Hamano]

Jeff King <peff@peff.net> writes:

> A common thing to grep for is the name of a symbol. This
> patch teaches the completion for "git grep" to look in
> a 'tags' file, if present, to complete a pattern. For
> example, in git.git:
>
>   $ make tags
>   $ git grep get_sha1<Tab><Tab>
>   get_sha1                 get_sha1_oneline
>   get_sha1_1               get_sha1_with_context
>   get_sha1_basic           get_sha1_with_context_1
>   get_sha1_hex             get_sha1_with_mode
>   get_sha1_hex_segment     get_sha1_with_mode_1
>   get_sha1_mb
>
> Signed-off-by: Jeff King <peff@peff.net>
> ---
> It's debatable whether this belongs in the generic completion code, as
> it really only works if your project uses ctags. But I find it to be a
> huge timesaver for finding callsites of functions, especially when
> coupled with "git jump grep" from the previous patch.

Could you elaborate a bit more on how this would help for finding
callsites? You are looking at a function and do not want to break its
callers, so at that point presumably you already know the name of the
function, no?

Ahh, Ok, you do not necessarily want to type the long function name.

By the way, I notice that "make tags" runs "find ." looking for any files
and directories that match "*.[hcS]" (so do $(ETAGS_TARGET) and cscope),
without even excluding .git metadirectory.

Perhaps something like this is in order?

 Makefile |   14 +++++++++++---
 1 files changed, 11 insertions(+), 3 deletions(-)

diff --git a/Makefile b/Makefile
index 17404c4..b38f55b 100644
--- a/Makefile
+++ b/Makefile
@@ -2127,17 +2127,25 @@ po/git.pot: $(LOCALIZED_C)
 
 pot: po/git.pot
 
+git_check = $(shell git ls-files >/dev/null 2>&1; echo $$?)
+ifeq ($(git_check),0)
+FIND_SOURCE_FILES = git ls-files '*.[hcS]'
+else
+FIND_SOURCE_FILES = $(FIND) . \( -name .git -type d -prune \) \
+		-o \( -name '*.[hcS]' -type f -print \)
+endif
+
 $(ETAGS_TARGET): FORCE
 	$(RM) $(ETAGS_TARGET)
-	$(FIND) . -name '*.[hcS]' -print | xargs etags -a -o $(ETAGS_TARGET)
+	$(FIND_SOURCE_FILES) | xargs etags -a -o $(ETAGS_TARGET)
 
 tags: FORCE
 	$(RM) tags
-	$(FIND) . -name '*.[hcS]' -print | xargs ctags -a
+	$(FIND_SOURCE_FILES) | xargs ctags -a
 
 cscope:
 	$(RM) cscope*
-	$(FIND) . -name '*.[hcS]' -print | xargs cscope -b
+	$(FIND_SOURCE_FILES) | xargs cscope -b
 
 ### Detect prefix changes
 TRACK_CFLAGS = $(CC):$(subst ','\'',$(ALL_CFLAGS)):\

Re: [PATCH 3/3] completion: match ctags symbol names in grep patterns

[Jonathan Nieder]

Junio C Hamano wrote:

> Perhaps something like this is in order?
[...]
> +++ b/Makefile
> @@ -2127,17 +2127,25 @@ po/git.pot: $(LOCALIZED_C)
>  
>  pot: po/git.pot
>  
> +git_check = $(shell git ls-files >/dev/null 2>&1; echo $$?)
> +ifeq ($(git_check),0)
> +FIND_SOURCE_FILES = git ls-files '*.[hcS]'
> +else
> +FIND_SOURCE_FILES = $(FIND) . \( -name .git -type d -prune \) \
> +		-o \( -name '*.[hcS]' -type f -print \)
> +endif

Neat.  I'd prefer something like

	FIND_SOURCE_FILES = \
		git ls-files '*.[hcS]' 2>/dev/null || \
		$(FIND) . -name .git -prune -o -name '*.[hcS]' -type f -print

that avoid punishing people who were using the makefile for some
purpose unrelated to tags and cscope, though. ;)

Re: [PATCH 3/3] completion: match ctags symbol names in grep patterns

[Junio C Hamano]

Jonathan Nieder <jrnieder@gmail.com> writes:

> Junio C Hamano wrote:
>
>> Perhaps something like this is in order?
> [...]
>> +++ b/Makefile
>> @@ -2127,17 +2127,25 @@ po/git.pot: $(LOCALIZED_C)
>>  
>>  pot: po/git.pot
>>  
>> +git_check = $(shell git ls-files >/dev/null 2>&1; echo $$?)
>> +ifeq ($(git_check),0)
>> +FIND_SOURCE_FILES = git ls-files '*.[hcS]'
>> +else
>> +FIND_SOURCE_FILES = $(FIND) . \( -name .git -type d -prune \) \
>> +		-o \( -name '*.[hcS]' -type f -print \)
>> +endif
>
> Neat.  I'd prefer something like
>
> 	FIND_SOURCE_FILES = \
> 		git ls-files '*.[hcS]' 2>/dev/null || \
> 		$(FIND) . -name .git -prune -o -name '*.[hcS]' -type f -print
>
> that avoid punishing people who were using the makefile for some
> purpose unrelated to tags and cscope, though. ;)

Hmm, how would this punish anybody exactly (I just took the structure
from the way how the auto-depend is done)?

Besides, you would need to have the whole thing in a subshell or
something, as this is used as the upstream to "| xargs".

Re: [PATCH 3/3] completion: match ctags symbol names in grep patterns

[Matthieu Moy]

Junio C Hamano <gitster@pobox.com> writes:

>>> +git_check = $(shell git ls-files >/dev/null 2>&1; echo $$?)
>>> +ifeq ($(git_check),0)

> Hmm, how would this punish anybody exactly (I just took the structure
> from the way how the auto-depend is done)?

The "shell git ls-files" is ran unconditionnally, hence a small
performance penality even if you don't run ctags.

-- 
Matthieu Moy
http://www-verimag.imag.fr/~moy/

Re: [PATCH 3/3] completion: match ctags symbol names in grep patterns

[Junio C Hamano]

Matthieu Moy <Matthieu.Moy@grenoble-inp.fr> writes:

> Junio C Hamano <gitster@pobox.com> writes:
>
>>>> +git_check = $(shell git ls-files >/dev/null 2>&1; echo $$?)
>>>> +ifeq ($(git_check),0)
>
>> Hmm, how would this punish anybody exactly (I just took the structure
>> from the way how the auto-depend is done)?
>
> The "shell git ls-files" is ran unconditionnally, hence a small
> performance penality even if you don't run ctags.

You mean it is run once whenever you type "make <RETURN>"?  Doesn't the
same argument apply for the auto-depend thingy against "make doc<RETURN>"?

Re: [PATCH 3/3] completion: match ctags symbol names in grep patterns

[Jonathan Nieder]

Junio C Hamano wrote:
> Jonathan Nieder <jrnieder@gmail.com> writes:
>> Junio C Hamano wrote:

>>> +git_check = $(shell git ls-files >/dev/null 2>&1; echo $$?)
[...]
>> Neat.  I'd prefer something like
[...]
>> that avoid punishing people who were using the makefile for some
>> purpose unrelated to tags and cscope, though. ;)
>
> Hmm, how would this punish anybody exactly (I just took the structure
> from the way how the auto-depend is done)?

As Matthieu mentioned, the code in $(shell ...) gets run once each
time the makefile is loaded, adding to the runtime and possible
failure modes of

	make clean

that does not care about the result.  The dep_check test has that same
problem, and I was a little nervous about that when we added it.  But:

 i.   it seemed to be worth the convenience

 ii.  computing whether the compiler supports -MMD once each time $(CC)
      is launched would slow enough not to be an option

 iii. in the end, most uses of the makefile are to compile something,
      anyway, so it is not _that_ much of a waste.

 iv.  if someone finds the per-make-invocation to be too high, we
      could introduce a DONT_COMPUTE_HEADER_DEPENDENCIES variable that
      causes the check to be skipped by forcing that particular result.

Great.

In this new tags/cscope example, one could make an argument that
running exactly once is similarly better than running as needed (as in
(ii) above), by pointing out that

	make tags TAGS cscope

would have to check for a working "git ls-files" once instead of three
times.  But I don't buy it. :)

> Besides, you would need to have the whole thing in a subshell or
> something, as this is used as the upstream to "| xargs".

Good catch, thanks.

Re: [PATCH 3/3] completion: match ctags symbol names in grep patterns

[Junio C Hamano]

Jonathan Nieder <jrnieder@gmail.com> writes:

> In this new tags/cscope example, one could make an argument that
> running exactly once is similarly better than running as needed (as in
> (ii) above), by pointing out that
>
> 	make tags TAGS cscope
>
> would have to check for a working "git ls-files" once instead of three
> times.

I tend to agree that once instead of three times is not such an
improvement, especially given how cheap builtin-invocation of ls-files is,
but then once every invocation of $(MAKE) would also be negligible (it is
not once every internal target evaluation).

In any case, here is what I'll queue. I like the fact that your suggestion
avoids an extra "test invocation" that spends cycles to read the full
index without contributing to the end result.

By the way, did anybody know that "git ls-files >/dev/null" is more
expensive than "git ls-files '~/' >/dev/null" as a way to see if there is
ls-files command available?

-- >8 --
Subject: [PATCH] Makefile: ask "ls-files" to list source files if available

The [ce]tags and cscope targets used to run "find" looking for any paths
that match '*.[chS]' to feed the list of source files to downstream xargs.

Use "git ls-files" if it is already available to us, and otherwise use a
tighter "find" expression that does not list directories and does not go
into our .git directory.

Signed-off-by: Junio C Hamano <gitster@pobox.com>
---
 Makefile |   10 +++++++---
 1 files changed, 7 insertions(+), 3 deletions(-)

diff --git a/Makefile b/Makefile
index 8d6d451..badfb77 100644
--- a/Makefile
+++ b/Makefile
@@ -2115,17 +2115,21 @@ po/git.pot: $(LOCALIZED_C)
 
 pot: po/git.pot
 
+FIND_SOURCE_FILES = ( git ls-files '*.[hcS]' 2>/dev/null || \
+			$(FIND) . \( -name .git -type d -prune \) \
+				-o \( -name '*.[hcS]' -type f -print \) )
+
 $(ETAGS_TARGET): FORCE
 	$(RM) $(ETAGS_TARGET)
-	$(FIND) . -name '*.[hcS]' -print | xargs etags -a -o $(ETAGS_TARGET)
+	$(FIND_SOURCE_FILES) | xargs etags -a -o $(ETAGS_TARGET)
 
 tags: FORCE
 	$(RM) tags
-	$(FIND) . -name '*.[hcS]' -print | xargs ctags -a
+	$(FIND_SOURCE_FILES) | xargs ctags -a
 
 cscope:
 	$(RM) cscope*
-	$(FIND) . -name '*.[hcS]' -print | xargs cscope -b
+	$(FIND_SOURCE_FILES) | xargs cscope -b
 
 ### Detect prefix changes
 TRACK_CFLAGS = $(CC):$(subst ','\'',$(ALL_CFLAGS)):\
-- 
1.7.7.388.g3a4b7

Re: [PATCH 3/3] completion: match ctags symbol names in grep patterns

[Jeff King]

On Tue, Oct 18, 2011 at 12:15:23AM -0700, Junio C Hamano wrote:

> > It's debatable whether this belongs in the generic completion code, as
> > it really only works if your project uses ctags. But I find it to be a
> > huge timesaver for finding callsites of functions, especially when
> > coupled with "git jump grep" from the previous patch.
> 
> Could you elaborate a bit more on how this would help for finding
> callsites? You are looking at a function and do not want to break its
> callers, so at that point presumably you already know the name of the
> function, no?
> 
> Ahh, Ok, you do not necessarily want to type the long function name.

Exactly. Actually, it is often not so much "do not want to type" as
"cannot remember the exact name", but the effect is the same. :)

I use the same completion for "vim -t" which will jump to the
definition.

> By the way, I notice that "make tags" runs "find ." looking for any files
> and directories that match "*.[hcS]" (so do $(ETAGS_TARGET) and cscope),
> without even excluding .git metadirectory.
> 
> Perhaps something like this is in order?
> [...]
> +FIND_SOURCE_FILES = git ls-files '*.[hcS]'

Makes sense to me. I doubt it matters much in practice, though, as we
don't tend to have random untracked source files lying around.

My version of ctags will actually do the recursion itself with "ctags
-R", picking out any files with with languages it knows about. But maybe
not all versions do that.

Also, I have often found myself trying to do completion on shell
functions. I wonder if it's worth adding them to the list (again, my
version of ctags understands bourne shell just fine, but I don't know if
all do).

-Peff

Re: [PATCH 3/3] completion: match ctags symbol names in grep patterns

[SZEDER Gábor]

Hi,


On Tue, Oct 18, 2011 at 01:01:05AM -0400, Jeff King wrote:
> A common thing to grep for is the name of a symbol. This
> patch teaches the completion for "git grep" to look in
> a 'tags' file, if present, to complete a pattern. For
> example, in git.git:
> 
>   $ make tags
>   $ git grep get_sha1<Tab><Tab>
>   get_sha1                 get_sha1_oneline
>   get_sha1_1               get_sha1_with_context
>   get_sha1_basic           get_sha1_with_context_1
>   get_sha1_hex             get_sha1_with_mode
>   get_sha1_hex_segment     get_sha1_with_mode_1
>   get_sha1_mb
> 
> Signed-off-by: Jeff King <peff@peff.net>
> ---
> It's debatable whether this belongs in the generic completion code, as
> it really only works if your project uses ctags. But I find it to be a
> huge timesaver for finding callsites of functions

Interesting idea.  I reckon most of the time I do 'git grep' in order
to find callsites of a function or usage of a global variable.  I
usually do that by copy-pasting the symbol name, but this change could
likely spare me that copy-paste.

>  contrib/completion/git-completion.bash |   11 +++++++++++
>  1 files changed, 11 insertions(+), 0 deletions(-)
> 
> diff --git a/contrib/completion/git-completion.bash b/contrib/completion/git-completion.bash
> index 8648a36..f4ab13d 100755
> --- a/contrib/completion/git-completion.bash
> +++ b/contrib/completion/git-completion.bash
> @@ -1432,6 +1432,10 @@ _git_gitk ()
>  	_gitk
>  }
>  
> +_git_grep_ctag_match() {

This is a helper function, therefore it should have two underscores as
prefix, i.e. __git_grep_ctag_match().  Single underscore prefixes are
"reserved" for completion functions of the corresponding git command,
i.e. if someone ever creates a git command or alias called
'grep_ctag_match', then 'git grep_ctag_match <TAB>' will invoke this
function to offer possible completion words.

> +	awk -v ORS=' ' "/^${1////\\/}/ { print \$1 }" "$2"
> +}
> +
>  _git_grep ()
>  {
>  	__git_has_doubledash && return
> @@ -1454,6 +1458,13 @@ _git_grep ()
>  		;;
>  	esac
>  
> +	case "$COMP_CWORD,$prev" in

Depending on what is on the command line before the current word,
$COMP_CWORD might have different value in Bash 3 and in Bash 4; see
da48616f (bash: get --pretty=m<tab> completion to work with bash v4,
2010-12-02).  Please use $cword instead.

> +	2,*|*,-*)
> +		test -r tags || return

1. This checks for the tags file in the current directory, so it would
   only work at the top of the working tree, but not in any of the
   subdirectories.

2. The return in case of no tags file would cause file name
   completion.  This is different from the current behavior, when the
   completion script would offer refs.  Now, I don't think that refs
   as grep pattern are any more useful than file names...  but neither
   do I think that offering file names is an improvement over current
   behavior.  Anyway, this is a side effect not mentioned in the
   commit message.

> +		COMPREPLY=( $(compgen -W "`_git_grep_ctag_match "$cur" tags`") )

1. Nit: $() around _git_grep_ctag_match().
   This would be the first backticks usage in the completion script.

2. When the completion script offers possible completion words, then
   usually a space is appended, e.g. 'git grep --e<TAB>' would
   complete to '--extended-regexp ', unless the offered option
   requires an argument, e.g. 'git commit --m<TAB>' would complete to
   '--message='.  I think function names extracted from the tags file
   should also get that trailing space.  No big deal, the easiest way
   to do that is to pass the output of _git_grep_ctag_match() to
   __gitcomp(), and it will take care of that.

   However, this change will make 'git grep <TAB>' offer 9868 possible
   completion words in my git repository, which is quite a lot.  I
   posted some completion optimizations recently, currently cooking in
   pu, which make processing that many possible completion words
   faster (sg/complete-refs, tip currently at 175901a5; the important
   commit is bd4139ca (completion: optimize refs completion,
   2011-10-15)).  To be able to use that optimization possible
   completion words must be separated by a newline, but your
   _git_grep_ctag_match() lists symbol names separated by a space.  It
   would be great if you could tweak _git_grep_ctag_match()'s awk
   script to list newline-separated symbols, so that when both
   branches are merged, then we could just change the __gitcomp() call
   to __gitcomp_nl().


Best,
Gábor

Re: [PATCH 3/3] completion: match ctags symbol names in grep patterns

[Jeff King]

On Fri, Oct 21, 2011 at 03:25:45PM +0200, SZEDER Gábor wrote:

> Interesting idea.  I reckon most of the time I do 'git grep' in order
> to find callsites of a function or usage of a global variable.  I
> usually do that by copy-pasting the symbol name, but this change could
> likely spare me that copy-paste.

Thanks. Glad somebody else finds it useful. :)

> > +_git_grep_ctag_match() {
> 
> This is a helper function, therefore it should have two underscores as
> prefix, i.e. __git_grep_ctag_match().  Single underscore prefixes are
> "reserved" for completion functions of the corresponding git command,
> i.e. if someone ever creates a git command or alias called
> 'grep_ctag_match', then 'git grep_ctag_match <TAB>' will invoke this
> function to offer possible completion words.

Good point. Will change.

> > +	case "$COMP_CWORD,$prev" in
> 
> Depending on what is on the command line before the current word,
> $COMP_CWORD might have different value in Bash 3 and in Bash 4; see
> da48616f (bash: get --pretty=m<tab> completion to work with bash v4,
> 2010-12-02).  Please use $cword instead.

Thanks, I was completely unaware of this issue.

> > +	2,*|*,-*)
> > +		test -r tags || return
> 
> 1. This checks for the tags file in the current directory, so it would
>    only work at the top of the working tree, but not in any of the
>    subdirectories.

Yeah. I didn't want to spend a lot of effort looking up through the
repository directories for a 'tags' file. Especially for people who
aren't using ctags at all, and for whom that would just be unnecessary
work.

OTOH, it is triggered only when they try to complete a pattern, which is
currently pointless. So maybe it's not worth worrying about existing
users, as they won't do this completion anyway.

> 2. The return in case of no tags file would cause file name
>    completion.  This is different from the current behavior, when the
>    completion script would offer refs.  Now, I don't think that refs
>    as grep pattern are any more useful than file names...  but neither
>    do I think that offering file names is an improvement over current
>    behavior.  Anyway, this is a side effect not mentioned in the
>    commit message.

Good point. Will fix.

> > +		COMPREPLY=( $(compgen -W "`_git_grep_ctag_match "$cur" tags`") )
> 
> 1. Nit: $() around _git_grep_ctag_match().
>    This would be the first backticks usage in the completion script.

Functionally irrelevant, I think, but style-wise, I agree it should
match the rest of the script.

> 2. When the completion script offers possible completion words, then
>    usually a space is appended, e.g. 'git grep --e<TAB>' would
>    complete to '--extended-regexp ', unless the offered option
>    requires an argument, e.g. 'git commit --m<TAB>' would complete to
>    '--message='.  I think function names extracted from the tags file
>    should also get that trailing space.  No big deal, the easiest way
>    to do that is to pass the output of _git_grep_ctag_match() to
>    __gitcomp(), and it will take care of that.

Thanks, I had wanted to add the space at one point, but forgot about it
and got used to the current behavior. I agree adding it is better, and
it's nice that it's easy to do.

>    However, this change will make 'git grep <TAB>' offer 9868 possible
>    completion words in my git repository, which is quite a lot.

Hmm. I never thought of that as much, but after converting to use
__gitcomp, there is a noticeable delay. I guess it's the loop of printfs
in __gitcomp_1.

...Ah, yes, reading your bd4139caa, it seems that is exactly the
problem.

>    I posted some completion optimizations recently, currently cooking
>    in pu, which make processing that many possible completion words
>    faster (sg/complete-refs, tip currently at 175901a5; the important
>    commit is bd4139ca (completion: optimize refs completion,
>    2011-10-15)).  To be able to use that optimization possible
>    completion words must be separated by a newline, but your
>    _git_grep_ctag_match() lists symbol names separated by a space.  It
>    would be great if you could tweak _git_grep_ctag_match()'s awk
>    script to list newline-separated symbols, so that when both
>    branches are merged, then we could just change the __gitcomp() call
>    to __gitcomp_nl().

Easy enough (just drop the ORS setting).

Thanks very much for your review. I have a fix for the first patch in
the series, too, so I'll send a whole new series in a moment.

-Peff

[PATCHv2 1/3] contrib: add diff highlight script

[Jeff King]

This is a simple and stupid script for highlighting
differing parts of lines in a unified diff. See the README
for a discussion of the limitations.

Signed-off-by: Jeff King <peff@peff.net>
---
Same as v1.

 contrib/diff-highlight/README         |   57 +++++++++++++++
 contrib/diff-highlight/diff-highlight |  124 +++++++++++++++++++++++++++++++++
 2 files changed, 181 insertions(+), 0 deletions(-)
 create mode 100644 contrib/diff-highlight/README
 create mode 100755 contrib/diff-highlight/diff-highlight

diff --git a/contrib/diff-highlight/README b/contrib/diff-highlight/README
new file mode 100644
index 0000000..1b7b6df
--- /dev/null
+++ b/contrib/diff-highlight/README
@@ -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
+---------------------------------------------
diff --git a/contrib/diff-highlight/diff-highlight b/contrib/diff-highlight/diff-highlight
new file mode 100755
index 0000000..d893898
--- /dev/null
+++ b/contrib/diff-highlight/diff-highlight
@@ -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]
+	);
+}
-- 
1.7.7.rc1.28.g5dd2ee

[PATCH 2/3] contrib: add git-jump script

[Jeff King]

This is a small script for helping your editor jump to
specific points of interest. See the README for details.

Signed-off-by: Jeff King <peff@peff.net>
---
This fixes a minor bug in v1 where doing "git jump merge" would display
the usage message when there were unmerged files, but none of the files
contained conflict markers (i.e., you had already fixed them up).

 contrib/git-jump/README   |   92 +++++++++++++++++++++++++++++++++++++++++++++
 contrib/git-jump/git-jump |   69 +++++++++++++++++++++++++++++++++
 2 files changed, 161 insertions(+), 0 deletions(-)
 create mode 100644 contrib/git-jump/README
 create mode 100755 contrib/git-jump/git-jump

diff --git a/contrib/git-jump/README b/contrib/git-jump/README
new file mode 100644
index 0000000..1cebc32
--- /dev/null
+++ b/contrib/git-jump/README
@@ -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).
diff --git a/contrib/git-jump/git-jump b/contrib/git-jump/git-jump
new file mode 100755
index 0000000..a33674e
--- /dev/null
+++ b/contrib/git-jump/git-jump
@@ -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"
-- 
1.7.7.rc1.28.g5dd2ee

Re: [PATCH 2/3] contrib: add git-jump script

[Jeff King]

On Fri, Oct 21, 2011 at 01:28:04PM -0400, Jeff King wrote:

> Subject: [PATCH 2/3] contrib: add git-jump script
> [...]
> This fixes a minor bug in v1 where doing "git jump merge" would display
> the usage message when there were unmerged files, but none of the files
> contained conflict markers (i.e., you had already fixed them up).

Oops, the subject should read "PATCHv2", obviously.

-Peff

[PATCHv2 3/3] completion: match ctags symbol names in grep patterns

[Jeff King]

A common thing to grep for is the name of a symbol. This
patch teaches the completion for "git grep" to look in
a 'tags' file, if present, to complete a pattern. For
example, in git.git:

  $ make tags
  $ git grep get_sha1<Tab><Tab>
  get_sha1                 get_sha1_oneline
  get_sha1_1               get_sha1_with_context
  get_sha1_basic           get_sha1_with_context_1
  get_sha1_hex             get_sha1_with_mode
  get_sha1_hex_segment     get_sha1_with_mode_1
  get_sha1_mb

Signed-off-by: Jeff King <peff@peff.net>
---
This incorporates the suggestions from Gábor's review, with one
exception: it still looks only in the current directory for the "tags"
files. I think that might have some performance implications, so I'd
rather add it separately, if at all.

 contrib/completion/git-completion.bash |   13 +++++++++++++
 1 files changed, 13 insertions(+), 0 deletions(-)

diff --git a/contrib/completion/git-completion.bash b/contrib/completion/git-completion.bash
index 888e8e1..af283cb 100755
--- a/contrib/completion/git-completion.bash
+++ b/contrib/completion/git-completion.bash
@@ -1429,6 +1429,10 @@ _git_gitk ()
 	_gitk
 }
 
+__git_match_ctag() {
+	awk "/^${1////\\/}/ { print \$1 }" "$2"
+}
+
 _git_grep ()
 {
 	__git_has_doubledash && return
@@ -1451,6 +1455,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)"
 }
 
-- 
1.7.7.rc1.28.g5dd2ee

[PATCHv2 4/3] completion: use __gitcomp_nl for ctag matching

[Jeff King]

On Fri, Oct 21, 2011 at 01:30:21PM -0400, Jeff King wrote:

> +		if test -r tags; then
> +			__gitcomp "$(__git_match_ctag "$cur" tags)"
> +			return
> +		fi

Once this is merged with sg/complete-refs, this can be applied on top:

-- >8 --
Subject: [PATCH] completion: use __gitcomp_nl for ctag matching

It's much faster than __gitcomp for large numbers of matches
(which ctags often have; there are almost 10,000 matches for
"" in git.git).

Signed-off-by: Jeff King <peff@peff.net>
---
As an aside, this is one of those patches that is easier to review using
"diff-highlight" from patch 1 of this series.

 contrib/completion/git-completion.bash |    2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/contrib/completion/git-completion.bash b/contrib/completion/git-completion.bash
index 391c054..53d3dcb 100755
--- a/contrib/completion/git-completion.bash
+++ b/contrib/completion/git-completion.bash
@@ -1473,7 +1473,7 @@ _git_grep ()
 	case "$cword,$prev" in
 	2,*|*,-*)
 		if test -r tags; then
-			__gitcomp "$(__git_match_ctag "$cur" tags)"
+			__gitcomp_nl "$(__git_match_ctag "$cur" tags)"
 			return
 		fi
 		;;
-- 
1.7.7.rc1.28.g5dd2ee

Re: [PATCHv2 3/3] completion: match ctags symbol names in grep patterns

[SZEDER Gábor]

Hi,

On Fri, Oct 21, 2011 at 01:30:21PM -0400, Jeff King wrote:
> This incorporates the suggestions from Gábor's review, with one
> exception: it still looks only in the current directory for the "tags"
> files. I think that might have some performance implications, so I'd
> rather add it separately, if at all.

I agree that scanning through a whole working tree for tags files
would cost too much.  But I think that a tags file at the top of the
working tree is common enough to be supported, and checking its
existence is fairly cheap.

> +	case "$cword,$prev" in
> +	2,*|*,-*)
> +		if test -r tags; then
> +			__gitcomp "$(__git_match_ctag "$cur" tags)"
> +			return
> +		fi
> +		;;

So how about something like this for the case arm? (I didn't actually
tested it.)

		local tagsfile
		if test -r tags; then
			tagsfile=tags
		else
			local dir="$(__gitdir)"
			if test -r "$dir"/tags; then
				tagsfile="$dir"/tags
			fi
		fi
		if [ -n "tagsfile" ]; then
			__gitcomp "$(__git_match_ctag "$cur" "$tagsfile")"
			return
		fi


Btw, there is a bug in the case statement: 'git --no-pager grep <TAB>'
offers refs instead of symbols, because $cword is not 2 and $prev
doesn't start with a dash.  But it's not worse than the current
behavior, so I don't think this bug is a show-stopper for the patch.


Best,
Gábor

Re: [PATCHv2 3/3] completion: match ctags symbol names in grep patterns

[Jeff King]

On Sun, Oct 23, 2011 at 11:29:28PM +0200, SZEDER Gábor wrote:

> On Fri, Oct 21, 2011 at 01:30:21PM -0400, Jeff King wrote:
> > This incorporates the suggestions from Gábor's review, with one
> > exception: it still looks only in the current directory for the "tags"
> > files. I think that might have some performance implications, so I'd
> > rather add it separately, if at all.
> 
> I agree that scanning through a whole working tree for tags files
> would cost too much.  But I think that a tags file at the top of the
> working tree is common enough to be supported, and checking its
> existence is fairly cheap.

Actually, it's not too expensive. Asking git for the top of the working
tree means it has to traverse up to there anyway. So the trick is just
doing our search without invoking too many external tools which would
cause unnecessary forks.

The patch is below, but I'm still not sure it's a good idea.

Grep only looks in the current subdirectory for matches. So if I am in
"src/foo/bar/", and the tags file is in "src/", then is it really a good
way to generate completions? Most of what's in the tags file will
probably be in _other_ subdirectories of "src/", and won't be matched by
grep at all. So we will give useless entries to bash to complete.

> So how about something like this for the case arm? (I didn't actually
> tested it.)
> 
> 		local tagsfile
> 		if test -r tags; then
> 			tagsfile=tags
> 		else
> 			local dir="$(__gitdir)"

You don't want __gitdir here, but rather "git rev-parse --show-cdup".

> Btw, there is a bug in the case statement: 'git --no-pager grep <TAB>'
> offers refs instead of symbols, because $cword is not 2 and $prev
> doesn't start with a dash.  But it's not worse than the current
> behavior, so I don't think this bug is a show-stopper for the patch.

Yeah. The intent of the "$cword is 2" thing is to know that we are the
first non-option argument. Arguably, _get_comp_words_by_ref should
somehow tell us which position we are completing relative to the actual
command name.

-Peff

---
diff --git a/contrib/completion/git-completion.bash b/contrib/completion/git-completion.bash
index af283cb..b0ed657 100755
--- a/contrib/completion/git-completion.bash
+++ b/contrib/completion/git-completion.bash
@@ -1429,6 +1429,39 @@ _git_gitk ()
 	_gitk
 }
 
+__git_cdup_dirs() {
+	local prefix=$(git rev-parse --show-cdup 2>/dev/null)
+	local oldifs=$IFS
+	local dots
+	local i
+	IFS=/
+	for i in $prefix; do
+		dots=$dots../
+		echo "$dots"
+	done
+	IFS=$oldifs
+}
+
+__git_find_in_cdup_one() {
+	local dir=$1; shift
+	for i in "$@"; do
+		if test -r "$dir$i"; then
+			echo "$dir$i"
+			return 0
+		fi
+	done
+	return 1
+}
+
+__git_find_in_cdup() {
+	__git_find_in_cdup_one "" "$@" && return
+
+	local dir
+	for dir in $(__git_cdup_dirs); do
+		__git_find_in_cdup_one "$dir" "$@" && return
+	done
+}
+
 __git_match_ctag() {
 	awk "/^${1////\\/}/ { print \$1 }" "$2"
 }
@@ -1457,8 +1490,9 @@ _git_grep ()
 
 	case "$cword,$prev" in
 	2,*|*,-*)
-		if test -r tags; then
-			__gitcomp "$(__git_match_ctag "$cur" tags)"
+		local tags=$(__git_find_in_cdup tags)
+		if test -n "$tags"; then
+			__gitcomp "$(__git_match_ctag "$cur" "$tags")"
 			return
 		fi
 		;;

Re: [PATCHv2 3/3] completion: match ctags symbol names in grep patterns

[SZEDER Gábor]

Hi,


On Thu, Oct 27, 2011 at 11:05:20PM -0700, Jeff King wrote:
> On Sun, Oct 23, 2011 at 11:29:28PM +0200, SZEDER Gábor wrote:
> 
> > On Fri, Oct 21, 2011 at 01:30:21PM -0400, Jeff King wrote:
> > > This incorporates the suggestions from Gábor's review, with one
> > > exception: it still looks only in the current directory for the "tags"
> > > files. I think that might have some performance implications, so I'd
> > > rather add it separately, if at all.
> > 
> > I agree that scanning through a whole working tree for tags files
> > would cost too much.  But I think that a tags file at the top of the
> > working tree is common enough to be supported, and checking its
> > existence is fairly cheap.
> 
> Actually, it's not too expensive. Asking git for the top of the working
> tree means it has to traverse up to there anyway. So the trick is just
> doing our search without invoking too many external tools which would
> cause unnecessary forks.
> 
> The patch is below, but I'm still not sure it's a good idea.
> 
> Grep only looks in the current subdirectory for matches.

Unless the user explicitly specifies the path(s)...  But that comes at
the end of the command line, so the completion script could have no
idea about it at the time of 'git grep <TAB>'.

> > So how about something like this for the case arm? (I didn't actually
> > tested it.)
> > 
> > 		local tagsfile
> > 		if test -r tags; then
> > 			tagsfile=tags
> > 		else
> > 			local dir="$(__gitdir)"
> 
> You don't want __gitdir here, but rather "git rev-parse --show-cdup".

Oh, yes, indeed.

But there was a point in using __gitdir() here: it respects the
--git-dir= option.  Which brings up the question: what
should 'git --git-dir=/some/where/.git grep <TAB>' offer?

So in the end I agree that it's not a good idea.

> > Btw, there is a bug in the case statement: 'git --no-pager grep <TAB>'
> > offers refs instead of symbols, because $cword is not 2 and $prev
> > doesn't start with a dash.  But it's not worse than the current
> > behavior, so I don't think this bug is a show-stopper for the patch.
> 
> Yeah. The intent of the "$cword is 2" thing is to know that we are the
> first non-option argument. Arguably, _get_comp_words_by_ref should
> somehow tell us which position we are completing relative to the actual
> command name.

_get_comp_words_by_ref() is a general completion function, the purpose
of which is to provide a bash-version-independent equivalent of
$COMP_WORDS and $COMP_CWORD by working around the different word
splitting rules.  It doesn't know about git and its commands at all.

But there is the while loop in _git() that looks for the git command
(among other things) on the command line, which could store the index
of the command name in $words in a variable.  This variable could then
be used in that case statement (and probably in a couple of other
places, too).


Best,
Gábor


> ---
> diff --git a/contrib/completion/git-completion.bash b/contrib/completion/git-completion.bash
> index af283cb..b0ed657 100755
> --- a/contrib/completion/git-completion.bash
> +++ b/contrib/completion/git-completion.bash
> @@ -1429,6 +1429,39 @@ _git_gitk ()
>  	_gitk
>  }
>  
> +__git_cdup_dirs() {
> +	local prefix=$(git rev-parse --show-cdup 2>/dev/null)
> +	local oldifs=$IFS
> +	local dots
> +	local i
> +	IFS=/
> +	for i in $prefix; do
> +		dots=$dots../
> +		echo "$dots"
> +	done
> +	IFS=$oldifs
> +}

No need for $oldifs here; do a local IFS=/ instead, and then it just
goes out of scope when returning from the function.

> +
> +__git_find_in_cdup_one() {
> +	local dir=$1; shift
> +	for i in "$@"; do
> +		if test -r "$dir$i"; then
> +			echo "$dir$i"
> +			return 0
> +		fi
> +	done
> +	return 1
> +}
> +
> +__git_find_in_cdup() {
> +	__git_find_in_cdup_one "" "$@" && return
> +
> +	local dir
> +	for dir in $(__git_cdup_dirs); do
> +		__git_find_in_cdup_one "$dir" "$@" && return
> +	done
> +}
> +
>  __git_match_ctag() {
>  	awk "/^${1////\\/}/ { print \$1 }" "$2"
>  }
> @@ -1457,8 +1490,9 @@ _git_grep ()
>  
>  	case "$cword,$prev" in
>  	2,*|*,-*)
> -		if test -r tags; then
> -			__gitcomp "$(__git_match_ctag "$cur" tags)"
> +		local tags=$(__git_find_in_cdup tags)
> +		if test -n "$tags"; then
> +			__gitcomp "$(__git_match_ctag "$cur" "$tags")"
>  			return
>  		fi
>  		;;

Re: [PATCHv2 3/3] completion: match ctags symbol names in grep patterns

[Jeff King]

On Sat, Oct 29, 2011 at 02:47:55PM +0200, SZEDER Gábor wrote:

> > Grep only looks in the current subdirectory for matches.
> 
> Unless the user explicitly specifies the path(s)...  But that comes at
> the end of the command line, so the completion script could have no
> idea about it at the time of 'git grep <TAB>'.

True. But that's a more general problem. You have a 'tags' file that
presumably represents the working tree. But you are not necessarily
grepping there. You might be grepping something related (e.g., what's in
the index), which makes the tags file still a good guess.

But you might also be grepping some totally unrelated branch, in which
case this is not helpful.

I tend to think that we are OK erring on the side of using the 'tags'
file, even if it might be wrong, since otherwise we have nothing to
tab-complete. When the user hits <Tab>, they are asking us to make our
best guess, and if they know there is nothing to complete, they won't
hit <Tab>. So it's not like we're hurting some existing workflow.

And in that sense, maybe we should just do the "search back up the
working tree" thing. Sure, it may be return way more matches than are
accurate, but even that's better than having no tab-completion at all.

> > You don't want __gitdir here, but rather "git rev-parse --show-cdup".
> 
> Oh, yes, indeed.
> 
> But there was a point in using __gitdir() here: it respects the
> --git-dir= option.  Which brings up the question: what
> should 'git --git-dir=/some/where/.git grep <TAB>' offer?

I guess if core.worktree is set, it would look there instead (and ditto
for specifying --work-tree on the command line).  Handling those is such
a corner case that I'm not too concerned if we don't. And if somebody
really cares, they can fix the completion later to pick up magic like
that from the early part of the command line. I don't see it as a
blocker for an initial version of the patch.

> _get_comp_words_by_ref() is a general completion function, the purpose
> of which is to provide a bash-version-independent equivalent of
> $COMP_WORDS and $COMP_CWORD by working around the different word
> splitting rules.  It doesn't know about git and its commands at all.
> 
> But there is the while loop in _git() that looks for the git command
> (among other things) on the command line, which could store the index
> of the command name in $words in a variable.  This variable could then
> be used in that case statement (and probably in a couple of other
> places, too).

Yeah, that makes sense. Again, my inclination is to just leave that for
a further patch if somebody really wants to make the completion (for
this and any other positional slots) more accurate.

-Peff

Re: [PATCHv2 3/3] completion: match ctags symbol names in grep patterns

[Junio C Hamano]

Jeff King <peff@peff.net> writes:

> Yeah, that makes sense. Again, my inclination is to just leave that for
> a further patch if somebody really wants to make the completion (for
> this and any other positional slots) more accurate.

I tend to agree with your inclination. Let's go with the current simple
version and see if real users want something different.