* [PATCH v2 1/2] submodule: whitespace fix
From: Tay Ray Chuan @ 2011-10-21 13:49 UTC (permalink / raw)
To: Git Mailing List; +Cc: Junio C Hamano, Jens Lehmann
In-Reply-To: <1319204976-5076-1-git-send-email-rctay89@gmail.com>
Replace SPs with TAB.
Signed-off-by: Tay Ray Chuan <rctay89@gmail.com>
---
git-submodule.sh | 6 +++---
1 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/git-submodule.sh b/git-submodule.sh
index 7576d14..8e9e5ea 100755
--- a/git-submodule.sh
+++ b/git-submodule.sh
@@ -104,9 +104,9 @@ module_name()
re=$(printf '%s\n' "$1" | sed -e 's/[].[^$\\*]/\\&/g')
name=$( git config -f .gitmodules --get-regexp '^submodule\..*\.path$' |
sed -n -e 's|^submodule\.\(.*\)\.path '"$re"'$|\1|p' )
- test -z "$name" &&
- die "$(eval_gettext "No submodule mapping found in .gitmodules for path '\$path'")"
- echo "$name"
+ test -z "$name" &&
+ die "$(eval_gettext "No submodule mapping found in .gitmodules for path '\$path'")"
+ echo "$name"
}
#
--
1.7.6.msysgit.0.584.g2cbf
^ permalink raw reply related
* [PATCH v2 2/2] submodule::module_clone(): silence die() message from module_name()
From: Tay Ray Chuan @ 2011-10-21 13:49 UTC (permalink / raw)
To: Git Mailing List; +Cc: Junio C Hamano, Jens Lehmann
In-Reply-To: <1319204976-5076-2-git-send-email-rctay89@gmail.com>
The die() message that may occur in module_name() is not really relevant
to the user when called from module_clone(); the latter handles the
"failure" (no submodule mapping) anyway.
Analysis of other callsites is left to future work.
Acked-by: Jens Lehmann <Jens.Lehmann@web.de>
Signed-off-by: Tay Ray Chuan <rctay89@gmail.com>
---
git-submodule.sh | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/git-submodule.sh b/git-submodule.sh
index 8e9e5ea..5d29f82 100755
--- a/git-submodule.sh
+++ b/git-submodule.sh
@@ -124,7 +124,7 @@ module_clone()
reference="$3"
gitdir=
gitdir_base=
- name=$(module_name "$path")
+ name=$(module_name "$path" 2>/dev/null)
base_path=$(dirname "$path")
gitdir=$(git rev-parse --git-dir)
--
1.7.6.msysgit.0.584.g2cbf
^ permalink raw reply related
* Re: Breakage in master since 6d4bb3833c
From: Michael Haggerty @ 2011-10-21 14:01 UTC (permalink / raw)
To: SZEDER Gábor; +Cc: Junio C Hamano, git discussion list
In-Reply-To: <20111021122801.GA3799@goldbirke>
On 10/21/2011 02:28 PM, SZEDER Gábor wrote:
> On Fri, Oct 21, 2011 at 02:10:53PM +0200, Michael Haggerty wrote:
>> When testing reference-handling performance using my refperf script [1],
>> I noticed that there is a problem in master that I bisected down to
>>
>> 6d4bb3833c "fetch: verify we have everything we need before updating our
>> ref"
>>
>> When I run the following commands
>>
>> =======================================================
>> GIT=$(pwd)/git
>
>> $GIT fetch origin
>> Then the last "git fetch origin" command gives the following output:
>> remote: Counting objects: 3, done.
>> remote: Total 3 (delta 0), reused 0 (delta 0)
>> Unpacking objects: 100% (3/3), done.
>> usage: git rev-list [OPTION] <commit-id>... [ -- paths... ]
>
> I suspect this is the same issue as here:
>
> http://thread.gmane.org/gmane.comp.version-control.git/182339/focus=182357
Yes, you are right. Setting GIT=$(pwd)/bin-wrappers/git fixes the problem.
Thanks,
Michael
--
Michael Haggerty
mhagger@alum.mit.edu
http://softwareswirl.blogspot.com/
^ permalink raw reply
* Re: git grep --no-index and absolute paths don't work?
From: Junio C Hamano @ 2011-10-21 17:00 UTC (permalink / raw)
To: Bert Wesarg; +Cc: Git Mailing List
In-Reply-To: <CAKPyHN138OZRt_3PT5ChuTpSEuOdybnyAj8Baqr=3OD=y==jgw@mail.gmail.com>
Bert Wesarg <bert.wesarg@googlemail.com> writes:
> I'm currently totally confused, that a
>
> git grep --no-index foo /usr/include
>
> does not work. I know that the documentation says "in the current
> directory" for the --no-index flag.
I think "in the current directory" is just contrasting with "in the work
tree, ..." at the beginning of the DESCRIPTION section. We could say "in
the files" instead for clarity, and then add "when pathspec is not given,
files in the current directory is searched" or something.
The intent of "--no-index", originating from "git diff --no-index", is to
allow git tools to be used in non-git context, i.e. to files on the
filesystem.
"git grep --no-index" which is a later invention in the 1.7.0 era didn't
fully ignore "git"ness, and one such instance you fixed in this thread:
http://thread.gmane.org/gmane.comp.version-control.git/181484/focus=181485
I think this path normalization is another instance of us knowing a bit too
much of "git" even when we are told with "--no-index" that we are not
operating on a working tree associated with git.
^ permalink raw reply
* Re: Breakage in master since 6d4bb3833c
From: Junio C Hamano @ 2011-10-21 17:01 UTC (permalink / raw)
To: Michael Haggerty; +Cc: SZEDER Gábor, git discussion list
In-Reply-To: <4EA17B1D.9000900@alum.mit.edu>
Michael Haggerty <mhagger@alum.mit.edu> writes:
> Yes, you are right. Setting GIT=$(pwd)/bin-wrappers/git fixes the problem.
So in short, this was a false alarm crying wolf, and there was no problem?
^ permalink raw reply
* Re: [PATCH 3/3] completion: match ctags symbol names in grep patterns
From: Jeff King @ 2011-10-21 17:22 UTC (permalink / raw)
To: SZEDER Gábor; +Cc: git
In-Reply-To: <20111021132545.GA27385@goldbirke>
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
^ permalink raw reply
* [PATCHv2 1/3] contrib: add diff highlight script
From: Jeff King @ 2011-10-21 17:26 UTC (permalink / raw)
To: git
In-Reply-To: <20111021172239.GA22289@sigill.intra.peff.net>
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
^ permalink raw reply related
* [PATCH 2/3] contrib: add git-jump script
From: Jeff King @ 2011-10-21 17:28 UTC (permalink / raw)
To: git
In-Reply-To: <20111021172239.GA22289@sigill.intra.peff.net>
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
^ permalink raw reply related
* [PATCHv2 3/3] completion: match ctags symbol names in grep patterns
From: Jeff King @ 2011-10-21 17:30 UTC (permalink / raw)
To: git; +Cc: SZEDER Gábor
In-Reply-To: <20111021172239.GA22289@sigill.intra.peff.net>
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
^ permalink raw reply related
* Re: git grep --no-index and absolute paths don't work?
From: Bert Wesarg @ 2011-10-21 17:35 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Git Mailing List
In-Reply-To: <7vipni8el6.fsf@alter.siamese.dyndns.org>
On Fri, Oct 21, 2011 at 19:00, Junio C Hamano <gitster@pobox.com> wrote:
> Bert Wesarg <bert.wesarg@googlemail.com> writes:
>
>> I'm currently totally confused, that a
>>
>> git grep --no-index foo /usr/include
>>
>> does not work. I know that the documentation says "in the current
>> directory" for the --no-index flag.
>
> I think "in the current directory" is just contrasting with "in the work
> tree, ..." at the beginning of the DESCRIPTION section. We could say "in
> the files" instead for clarity, and then add "when pathspec is not given,
> files in the current directory is searched" or something.
>
> The intent of "--no-index", originating from "git diff --no-index", is to
> allow git tools to be used in non-git context, i.e. to files on the
> filesystem.
>
> "git grep --no-index" which is a later invention in the 1.7.0 era didn't
> fully ignore "git"ness, and one such instance you fixed in this thread:
>
> http://thread.gmane.org/gmane.comp.version-control.git/181484/focus=181485
>
Thats why I'm completely rattled after trying an absolute path with
--no-index and it didn't worked.
> I think this path normalization is another instance of us knowing a bit too
> much of "git" even when we are told with "--no-index" that we are not
> operating on a working tree associated with git.
>
So we agree that this is a bug. Good. I will try to have a look into this.
Bert
^ permalink raw reply
* Re: [PATCH 2/3] contrib: add git-jump script
From: Jeff King @ 2011-10-21 17:35 UTC (permalink / raw)
To: git
In-Reply-To: <20111021172804.GB24417@sigill.intra.peff.net>
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
^ permalink raw reply
* [PATCHv2 4/3] completion: use __gitcomp_nl for ctag matching
From: Jeff King @ 2011-10-21 17:37 UTC (permalink / raw)
To: git; +Cc: SZEDER Gábor
In-Reply-To: <20111021173021.GC24417@sigill.intra.peff.net>
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
^ permalink raw reply related
* REACH DANIEL GOH AT sch@soyof.com
From: Melisa Taufiq @ 2011-10-21 17:46 UTC (permalink / raw)
My name is Melisa Taufiq, i am going on a cancer surgery today. I have WILL Seventeen Million United States Dollars to you for the work of the lord. Contact my
attorney with my reference number FZ/XXR/729/0537/BKH0/613X1/UK for further info. Barr.Daniel Goh at sch(at)soyof com. Melisa Taufiq
^ permalink raw reply
* [PATCH] Add simple test for Git::config_path() in t/t9700-perl-git.sh
From: Jakub Narebski @ 2011-10-21 18:42 UTC (permalink / raw)
To: git; +Cc: Junio C Hamano, Eric Wong, Cord Seele, Matthieu Moy, Cord Seele
Tests "~/foo" path expansion and multiple values.
Signed-off-by: Jakub Narebski <jnareb@gmail.com>
---
t/t9700-perl-git.sh | 6 +++++-
t/t9700/test.pl | 4 ++++
2 files changed, 9 insertions(+), 1 deletions(-)
diff --git a/t/t9700-perl-git.sh b/t/t9700-perl-git.sh
index 3787186..435d896 100755
--- a/t/t9700-perl-git.sh
+++ b/t/t9700-perl-git.sh
@@ -43,7 +43,11 @@ test_expect_success \
git config --add test.booltrue true &&
git config --add test.boolfalse no &&
git config --add test.boolother other &&
- git config --add test.int 2k
+ git config --add test.int 2k &&
+ git config --add test.path "~/foo" &&
+ git config --add test.pathexpanded "$HOME/foo" &&
+ git config --add test.pathmulti foo &&
+ git config --add test.pathmulti bar
'
# The external test will outputs its own plan
diff --git a/t/t9700/test.pl b/t/t9700/test.pl
index 13ba96e..3b9b484 100755
--- a/t/t9700/test.pl
+++ b/t/t9700/test.pl
@@ -33,6 +33,10 @@ is($r->config_int("test.int"), 2048, "config_int: integer");
is($r->config_int("test.nonexistent"), undef, "config_int: nonexistent");
ok($r->config_bool("test.booltrue"), "config_bool: true");
ok(!$r->config_bool("test.boolfalse"), "config_bool: false");
+is($r->config_path("test.path"), $r->config("test.pathexpanded"),
+ "config_path: ~/foo expansion");
+is_deeply([$r->config_path("test.pathmulti")], ["foo", "bar"],
+ "config_path: multiple values");
our $ansi_green = "\x1b[32m";
is($r->get_color("color.test.slot1", "red"), $ansi_green, "get_color");
# Cannot test $r->get_colorbool("color.foo")) because we do not
^ permalink raw reply related
* [PATCH] gitweb: fix regression when filtering out forks
From: Julien Muchembled @ 2011-10-21 19:04 UTC (permalink / raw)
To: git, Jakub Narebski; +Cc: Julien Muchembled
This fixes a condition in filter_forks_from_projects_list that failed if
process directory was different from project root: in such case, the subroutine
was a no-op and forks were not detected.
Signed-off-by: Julien Muchembled <jm@jmuchemb.eu>
---
gitweb/gitweb.perl | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/gitweb/gitweb.perl b/gitweb/gitweb.perl
index 70a576a..206e2a6 100755
--- a/gitweb/gitweb.perl
+++ b/gitweb/gitweb.perl
@@ -2875,7 +2875,7 @@ sub filter_forks_from_projects_list {
$path =~ s/\.git$//; # forks of 'repo.git' are in 'repo/' directory
next if ($path =~ m!/$!); # skip non-bare repositories, e.g. 'repo/.git'
next unless ($path); # skip '.git' repository: tests, git-instaweb
- next unless (-d $path); # containing directory exists
+ next unless (-d "$projectroot/$path"); # containing directory exists
$pr->{'forks'} = []; # there can be 0 or more forks of project
# add to trie
--
1.7.7.731.g3af63.dirty
^ permalink raw reply related
* Re: [PATCH] gitweb: provide a way to customize html headers
From: Jakub Narebski @ 2011-10-21 19:14 UTC (permalink / raw)
To: Lénaïc Huard; +Cc: git
In-Reply-To: <201110210046.34679.lenaic@lhuard.fr.eu.org>
Dnia piątek 21. października 2011 00:46, Lénaïc Huard napisał:
> Le lundi 17 octobre 2011, Jakub Narebski a écrit :
>> On Mon, 17 Oct 2011, Lénaïc Huard wrote:
>>> Jakub Narebski <jnareb@gmail.com> writes:
>>>> Lénaïc Huard <lenaic@lhuard.fr.eu.org> writes:
[...]
>>>>> gitweb/INSTALL | 3 +++
>>>>
>>>> Nb. there is patch in flight adding gitweb.conf(5) and gitweb(1)
>>>> manpages...
>>>
>>> Ok. So, I’ll update them once a decision will be taken concerning this
>>> $site_htmlheader.
>>
>> You might have to wait a bit till patches containing gitweb.conf(5)
>> manpage are merged in, and rebase your patch to add information about
>> new config variable not to gitweb/INSTALL, but to
>> Documentation/gitweb.conf.txt
>
> I added the documentation to Documentation/gitweb.conf.txt.
> But, as I noticed that gitweb/INSTALL still exists and still documents the
> old variables, I left the doc of the new one.
>
> Documentation/gitweb.conf.txt | 5 +++++
> gitweb/INSTALL | 2 ++
> gitweb/Makefile | 2 ++
> gitweb/gitweb.perl | 7 +++++++
> t/gitweb-lib.sh | 1 +
> 5 files changed, 17 insertions(+), 0 deletions(-)
Well, gitweb/INSTALL documents _build_ time [make] variables, and that
didn't change with introduction of gitweb manpages. Those are important
only during explanation.
It is only runtime _configuration_ that moved from gitweb/README (which
should be short description of project) to manpages for gitweb config.
--
Jakub Narebski
Poland
^ permalink raw reply
* Re: [PATCH v2 2/2] daemon: report permission denied error to clients
From: Junio C Hamano @ 2011-10-21 19:25 UTC (permalink / raw)
To: Clemens Buchacher; +Cc: git, Jeff King
In-Reply-To: <20111017195850.GC29479@ecki>
Clemens Buchacher <drizzd@aon.at> writes:
> diff --git a/daemon.c b/daemon.c
> index 72fb53a..2f7f84e 100644
> --- a/daemon.c
> +++ b/daemon.c
> @@ -120,12 +120,14 @@ static char *path_ok(char *directory)
>
> if (daemon_avoid_alias(dir)) {
> logerror("'%s': aliased", dir);
> + errno = 0;
> return NULL;
> }
>
> if (*dir == '~') {
> if (!user_path) {
> logerror("'%s': User-path not allowed", dir);
> + errno = EACCES;
> return NULL;
> }
Isn't the first one inconsistent from all the others?
A request cames "../some/path" and it is not allowed by a daemon policy
and it gets errno==0 which is turned into "no such repo" later, while
another request to "~drizzed/another/path" is also rejected by a daemon
policy and gets errno==EACCESS which is turned into "permission denied".
Indeed everything else says EACCESS in this patch, except for the check
done by enter_repo() which can additionally say ENAMETOOLONG (which would
not be very useful in practice) or whatever error coming from failure to
go there with chdir(), which is not likely to be EACCESS because it has
already been checked with a separate access() that is done before the
actual chdir() call.
> + if (!(path = path_ok(dir))) {
> + if (errno == EACCES)
> + return daemon_error(dir, "permission denied");
> + else
> + return daemon_error(dir, "no such repository");
> + }
If errno is set to EACCESS in cases (1) we are not even going to tell you
if a repository exists there or not--you are not authorized to know and
(2) there is a repository but you do not have authorization to access it,
then this "leaking a bit more information" part is acceptable for site
with "--informative-errors", I would think. A repository that is invalid
from the daemon's point of view (e.g. validate_headref("HEAD") fails
because it points at an object that does not exist) but that the owner
intended to make it valid by correcting such mistakes would be reported as
"no such repository" with such a logic, so I am not sure if the distinction
between these two cases really matters in practice, though.
^ permalink raw reply
* [PATCH 1/3] MSVC: Compile fix by not including sys/resources.h
From: Vincent van Ravesteijn @ 2011-10-21 19:36 UTC (permalink / raw)
To: git
Fix compilation when compiling with MSVC because sys/resource.h
is not available. This patch causes a number of other headerfiles
that are not available to be excluded as well.
Signed-off-by: Vincent van Ravesteijn <vfr@lyx.org>
---
git-compat-util.h | 13 ++++++-------
1 files changed, 6 insertions(+), 7 deletions(-)
diff --git a/git-compat-util.h b/git-compat-util.h
index 5ef8ff7..53186da 100644
--- a/git-compat-util.h
+++ b/git-compat-util.h
@@ -116,7 +116,12 @@
#else
#include <poll.h>
#endif
-#ifndef __MINGW32__
+#if defined(__MINGW32__)
+/* pull in Windows compatibility stuff */
+#include "compat/mingw.h"
+#elif defined(_MSC_VER)
+#include "compat/msvc.h"
+#else
#include <sys/wait.h>
#include <sys/resource.h>
#include <sys/socket.h>
@@ -145,12 +150,6 @@
#include <grp.h>
#define _ALL_SOURCE 1
#endif
-#else /* __MINGW32__ */
-/* pull in Windows compatibility stuff */
-#include "compat/mingw.h"
-#endif /* __MINGW32__ */
-#ifdef _MSC_VER
-#include "compat/msvc.h"
#endif
#ifndef NO_LIBGEN_H
--
1.7.6.msysgit.0
^ permalink raw reply related
* [PATCH 2/3] MSVC: Compile fix by including io.h
From: Vincent van Ravesteijn @ 2011-10-21 19:39 UTC (permalink / raw)
To: git
In-Reply-To: <4EA1C9C9.9010904@lyx.org>
Include io.h when compiling with MSVC
Signed-off-by: Vincent van Ravesteijn <vfr@lyx.org>
---
compat/msvc.h | 1 +
1 files changed, 1 insertions(+), 0 deletions(-)
diff --git a/compat/msvc.h b/compat/msvc.h
index a33b01c..aa4b563 100644
--- a/compat/msvc.h
+++ b/compat/msvc.h
@@ -4,6 +4,7 @@
#include <direct.h>
#include <process.h>
#include <malloc.h>
+#include <io.h>
/* porting function */
#define inline __inline
--
1.7.6.msysgit.0
^ permalink raw reply related
* [PATCH 3/3] MSVC: Remove unneeded header stubs
From: Vincent van Ravesteijn @ 2011-10-21 19:42 UTC (permalink / raw)
To: git
In-Reply-To: <4EA1C9C9.9010904@lyx.org>
These headers are not necessary anymore as they are no longer included
in git-compat-util.h.
Signed-off-by: Vincent van Ravesteijn <vfr@lyx.org>
---
compat/vcbuild/include/arpa/inet.h | 1 -
compat/vcbuild/include/grp.h | 1 -
compat/vcbuild/include/inttypes.h | 1 -
compat/vcbuild/include/netdb.h | 1 -
compat/vcbuild/include/netinet/in.h | 1 -
compat/vcbuild/include/netinet/tcp.h | 1 -
compat/vcbuild/include/pwd.h | 1 -
compat/vcbuild/include/sys/ioctl.h | 1 -
compat/vcbuild/include/sys/select.h | 1 -
compat/vcbuild/include/sys/socket.h | 1 -
compat/vcbuild/include/sys/wait.h | 1 -
compat/vcbuild/include/termios.h | 1 -
12 files changed, 0 insertions(+), 12 deletions(-)
delete mode 100644 compat/vcbuild/include/arpa/inet.h
delete mode 100644 compat/vcbuild/include/grp.h
delete mode 100644 compat/vcbuild/include/inttypes.h
delete mode 100644 compat/vcbuild/include/netdb.h
delete mode 100644 compat/vcbuild/include/netinet/in.h
delete mode 100644 compat/vcbuild/include/netinet/tcp.h
delete mode 100644 compat/vcbuild/include/pwd.h
delete mode 100644 compat/vcbuild/include/sys/ioctl.h
delete mode 100644 compat/vcbuild/include/sys/select.h
delete mode 100644 compat/vcbuild/include/sys/socket.h
delete mode 100644 compat/vcbuild/include/sys/wait.h
delete mode 100644 compat/vcbuild/include/termios.h
diff --git a/compat/vcbuild/include/arpa/inet.h
b/compat/vcbuild/include/arpa/inet.h
deleted file mode 100644
index 0d8552a..0000000
--- a/compat/vcbuild/include/arpa/inet.h
+++ /dev/null
@@ -1 +0,0 @@
-/* Intentionally empty file to support building git with MSVC */
diff --git a/compat/vcbuild/include/grp.h b/compat/vcbuild/include/grp.h
deleted file mode 100644
index 0d8552a..0000000
--- a/compat/vcbuild/include/grp.h
+++ /dev/null
@@ -1 +0,0 @@
-/* Intentionally empty file to support building git with MSVC */
diff --git a/compat/vcbuild/include/inttypes.h
b/compat/vcbuild/include/inttypes.h
deleted file mode 100644
index 0d8552a..0000000
--- a/compat/vcbuild/include/inttypes.h
+++ /dev/null
@@ -1 +0,0 @@
-/* Intentionally empty file to support building git with MSVC */
diff --git a/compat/vcbuild/include/netdb.h b/compat/vcbuild/include/netdb.h
deleted file mode 100644
index 0d8552a..0000000
--- a/compat/vcbuild/include/netdb.h
+++ /dev/null
@@ -1 +0,0 @@
-/* Intentionally empty file to support building git with MSVC */
diff --git a/compat/vcbuild/include/netinet/in.h
b/compat/vcbuild/include/netinet/in.h
deleted file mode 100644
index 0d8552a..0000000
--- a/compat/vcbuild/include/netinet/in.h
+++ /dev/null
@@ -1 +0,0 @@
-/* Intentionally empty file to support building git with MSVC */
diff --git a/compat/vcbuild/include/netinet/tcp.h
b/compat/vcbuild/include/netinet/tcp.h
deleted file mode 100644
index 0d8552a..0000000
--- a/compat/vcbuild/include/netinet/tcp.h
+++ /dev/null
@@ -1 +0,0 @@
-/* Intentionally empty file to support building git with MSVC */
diff --git a/compat/vcbuild/include/pwd.h b/compat/vcbuild/include/pwd.h
deleted file mode 100644
index 0d8552a..0000000
--- a/compat/vcbuild/include/pwd.h
+++ /dev/null
@@ -1 +0,0 @@
-/* Intentionally empty file to support building git with MSVC */
diff --git a/compat/vcbuild/include/sys/ioctl.h
b/compat/vcbuild/include/sys/ioctl.h
deleted file mode 100644
index 0d8552a..0000000
--- a/compat/vcbuild/include/sys/ioctl.h
+++ /dev/null
@@ -1 +0,0 @@
-/* Intentionally empty file to support building git with MSVC */
diff --git a/compat/vcbuild/include/sys/select.h
b/compat/vcbuild/include/sys/select.h
deleted file mode 100644
index 0d8552a..0000000
--- a/compat/vcbuild/include/sys/select.h
+++ /dev/null
@@ -1 +0,0 @@
-/* Intentionally empty file to support building git with MSVC */
diff --git a/compat/vcbuild/include/sys/socket.h
b/compat/vcbuild/include/sys/socket.h
deleted file mode 100644
index 0d8552a..0000000
--- a/compat/vcbuild/include/sys/socket.h
+++ /dev/null
@@ -1 +0,0 @@
-/* Intentionally empty file to support building git with MSVC */
diff --git a/compat/vcbuild/include/sys/wait.h
b/compat/vcbuild/include/sys/wait.h
deleted file mode 100644
index 0d8552a..0000000
--- a/compat/vcbuild/include/sys/wait.h
+++ /dev/null
@@ -1 +0,0 @@
-/* Intentionally empty file to support building git with MSVC */
diff --git a/compat/vcbuild/include/termios.h
b/compat/vcbuild/include/termios.h
deleted file mode 100644
index 0d8552a..0000000
--- a/compat/vcbuild/include/termios.h
+++ /dev/null
@@ -1 +0,0 @@
-/* Intentionally empty file to support building git with MSVC */
--
1.7.6.msysgit.0
^ permalink raw reply related
* [PATCH] git-svn: add hook to allow modifying the subversion commit message
From: Michael Lutz @ 2011-10-21 20:25 UTC (permalink / raw)
To: git; +Cc: Eric Wong, Michael Lutz
Sometimes modifying the commit message git-svn creates for a subversion
commit can be useful, for example if the original message contains meta
information not needed in the git clone or information from svn properties
should be stored visibly in the commit message.
This change adds a hook 'git-svn-msg' analogue to the 'commit-msg' hook.
Additionally to the commit message, the hook is passed the git-svn meta
data by an environment variable.
Signed-off-by: Michael Lutz <michi@icosahedron.de>
---
Documentation/githooks.txt | 19 +++++++++++++++++++
git-svn.perl | 25 +++++++++++++++++++++++++
templates/hooks--git-svn-msg.sample | 18 ++++++++++++++++++
3 files changed, 62 insertions(+), 0 deletions(-)
create mode 100755 templates/hooks--git-svn-msg.sample
diff --git a/Documentation/githooks.txt b/Documentation/githooks.txt
index 28edefa..dd90c1a 100644
--- a/Documentation/githooks.txt
+++ b/Documentation/githooks.txt
@@ -45,6 +45,25 @@ the commit after inspecting the message file.
The default 'applypatch-msg' hook, when enabled, runs the
'commit-msg' hook, if the latter is enabled.
+git-svn-msg
+~~~~~~~~~~~
+
+This hook is invoked by 'git svn' when creating a git commit
+from a subversion commit. It takes a single parameter, the name
+of the file that holds the original subversion commit message.
+Exiting with non-zero status causes 'git svn' to abbort before
+creating the git commit. Additional, the environment variable
+`GIT_SVN_METADATA=:` is set to the string that would appear
+after the 'git-svn-id:' line.
+
+The hook is allowed to edit the message file in place, and can
+be used to normalize the message into some project standard
+format (if the project has one). It can also be used to refuse
+the commit after inspecting the message file.
+
+The default 'git-svn-msg' hook, when enabled, runs the
+'commit-msg' hook, if the latter is enabled.
+
pre-applypatch
~~~~~~~~~~~~~~
diff --git a/git-svn.perl b/git-svn.perl
index b67fef0..030516c 100755
--- a/git-svn.perl
+++ b/git-svn.perl
@@ -3007,6 +3007,31 @@ sub do_git_commit {
require Encode;
Encode::from_to($log_entry->{log}, 'UTF-8', $enc);
}
+
+ # execute commit message hook if present
+ if (-x "$ENV{GIT_DIR}/hooks/git-svn-msg") {
+ print "Calling commit mesasage hook\n";
+
+ # write commit message to file
+ my $msg_file = "$ENV{GIT_DIR}/SVN_COMMIT_EDITMSG";
+ mkfile($msg_file);
+ open my $fh, '>', $msg_file or croak $!;
+ binmode $fh;
+ print $fh $log_entry->{log} or croak $!;
+ close $fh or croak $!;
+
+ $ENV{GIT_SVN_METADATA} = $log_entry->{metadata};
+ system("$ENV{GIT_DIR}/hooks/git-svn-msg", $msg_file);
+ die "git-svn-msg hook failed: $!\n" if $?;
+
+ # read commit message back
+ open $fh, '<', $msg_file or croak $!;
+ binmode $fh;
+ $log_entry->{log} = do { local $/; <$fh> };
+ close $fh or croak $!;
+ unlink $msg_file;
+ }
+
print $msg_fh $log_entry->{log} or croak $!;
restore_commit_header_env($old_env);
unless ($self->no_metadata) {
diff --git a/templates/hooks--git-svn-msg.sample b/templates/hooks--git-svn-msg.sample
new file mode 100755
index 0000000..6584fd8
--- /dev/null
+++ b/templates/hooks--git-svn-msg.sample
@@ -0,0 +1,18 @@
+#!/bin/sh
+#
+# An example hook script to check the commit log message taken by
+# git svn from a subversion commit.
+#
+# The hook should exit with non-zero status after issuing an
+# appropriate message if it wants to stop the commit. The hook is
+# allowed to edit the commit message file.
+#
+# GIT_SVN_METADATA will contain the same info as printed after
+# the git-svn-id line.
+#
+# To enable this hook, rename this file to "git-svn-msg".
+
+. git-sh-setup
+test -x "$GIT_DIR/hooks/commit-msg" &&
+ exec "$GIT_DIR/hooks/commit-msg" ${1+"$@"}
+:
--
1.7.5.1
^ permalink raw reply related
* Re: [PATCH] gitweb: fix regression when filtering out forks
From: Jakub Narebski @ 2011-10-21 20:51 UTC (permalink / raw)
To: Julien Muchembled; +Cc: git
In-Reply-To: <1319223861-10803-1-git-send-email-jm@jmuchemb.eu>
On Fri, 21 Oct 2011, Julien Muchembled wrote:
> This fixes a condition in filter_forks_from_projects_list that failed if
> process directory was different from project root: in such case, the subroutine
> was a no-op and forks were not detected.
>
> Signed-off-by: Julien Muchembled <jm@jmuchemb.eu>
Thanks.
I am embarrassed that I missed this; in the test I have added $projectroot
_is_ current directory for script. Anyway I have tested this in running
local installation on testsuite, and it now works (i.e. hide forks under
"+" character, where it would not before - gitweb shown every project).
Tested-by: Jakub Narebski <jnareb@gmail.com>
> ---
> gitweb/gitweb.perl | 2 +-
> 1 files changed, 1 insertions(+), 1 deletions(-)
>
> diff --git a/gitweb/gitweb.perl b/gitweb/gitweb.perl
> index 70a576a..206e2a6 100755
> --- a/gitweb/gitweb.perl
> +++ b/gitweb/gitweb.perl
> @@ -2875,7 +2875,7 @@ sub filter_forks_from_projects_list {
> $path =~ s/\.git$//; # forks of 'repo.git' are in 'repo/' directory
> next if ($path =~ m!/$!); # skip non-bare repositories, e.g. 'repo/.git'
> next unless ($path); # skip '.git' repository: tests, git-instaweb
> - next unless (-d $path); # containing directory exists
> + next unless (-d "$projectroot/$path"); # containing directory exists
> $pr->{'forks'} = []; # there can be 0 or more forks of project
>
> # add to trie
> --
--
Jakub Narebski
Poland
^ permalink raw reply
* Re: [PATCH] git-gui: use a tristate to control the case mode in the searchbar
From: Pat Thoyts @ 2011-10-21 21:41 UTC (permalink / raw)
To: Bert Wesarg; +Cc: Andrew Ardill, git
In-Reply-To: <9193677f1fef348d5b081653840e8a829ddd3e50.1319138692.git.bert.wesarg@googlemail.com>
Bert Wesarg <bert.wesarg@googlemail.com> writes:
>The config is now called gui.search.case and can have the three values:
>no/yes/smart. yes is the default.
>
>It also resets the case detection in smart mode, when the entry field was
>cleared by the use.
>
>Signed-off-by: Bert Wesarg <bert.wesarg@googlemail.com>
>---
> lib/search.tcl | 24 +++++++++++++++++-------
> 1 files changed, 17 insertions(+), 7 deletions(-)
>
>diff --git a/lib/search.tcl b/lib/search.tcl
>index 04a316b..ef1e555 100644
>--- a/lib/search.tcl
>+++ b/lib/search.tcl
>@@ -26,11 +26,20 @@ constructor new {i_w i_text args} {
> set ctext $i_text
>
> set default_regexpsearch [is_config_true gui.search.regexp]
>- set smartcase [is_config_true gui.search.smartcase]
>- if {$smartcase} {
>+ switch -- [get_config gui.search.case] {
>+ no {
> set default_casesensitive 0
>- } else {
>+ set smartcase 0
>+ }
>+ smart {
>+ set default_casesensitive 0
>+ set smartcase 1
>+ }
>+ yes -
>+ default {
> set default_casesensitive 1
>+ set smartcase 0
>+ }
> }
>
> set history [list]
>@@ -157,12 +166,10 @@ method _incrsearch {} {
> if {[catch {$ctext index anchor}]} {
> $ctext mark set anchor [_get_new_anchor $this]
> }
>- if {$smartcase} {
>- if {[regexp {[[:upper:]]} $searchstring]} {
>+ if {$searchstring ne {}} {
>+ if {$smartcase && [regexp {[[:upper:]]} $searchstring]} {
> set casesensitive 1
> }
>- }
>- if {$searchstring ne {}} {
> set here [_do_search $this anchor mlen]
> if {$here ne {}} {
> $ctext see $here
>@@ -175,6 +182,9 @@ method _incrsearch {} {
> #$w.ent configure -background lightpink
> $w.ent state pressed
> }
>+ } elseif {$smartcase} {
>+ # clearing the field resets the smart case detection
>+ set casesensitive 0
> }
> }
Look good to me. Applied.
--
Pat Thoyts http://www.patthoyts.tk/
PGP fingerprint 2C 6E 98 07 2C 59 C8 97 10 CE 11 E6 04 E0 B9 DD
^ permalink raw reply
* Re: [PATCH] git-gui: span widgets over the full file output area in the blame view
From: Pat Thoyts @ 2011-10-21 21:41 UTC (permalink / raw)
To: Bert Wesarg; +Cc: git
In-Reply-To: <16d7f36e4d24d8816035f934836395e5f854f1d3.1319138993.git.bert.wesarg@googlemail.com>
Bert Wesarg <bert.wesarg@googlemail.com> writes:
>Signed-off-by: Bert Wesarg <bert.wesarg@googlemail.com>
>---
> lib/blame.tcl | 9 ++++++---
> 1 files changed, 6 insertions(+), 3 deletions(-)
>
>diff --git a/lib/blame.tcl b/lib/blame.tcl
>index 49eae19..b031e66 100644
>--- a/lib/blame.tcl
>+++ b/lib/blame.tcl
>@@ -219,7 +219,8 @@ constructor new {i_commit i_path i_jump} {
> eval grid $w_columns $w.file_pane.out.sby -sticky nsew
> grid conf \
> $w.file_pane.out.sbx \
>- -column [expr {[llength $w_columns] - 1}] \
>+ -column 0 \
>+ -columnspan [expr {[llength $w_columns] + 1}] \
> -sticky we
> grid columnconfigure \
> $w.file_pane.out \
>@@ -229,12 +230,14 @@ constructor new {i_commit i_path i_jump} {
>
> set finder [::searchbar::new \
> $w.file_pane.out.ff $w_file \
>- -column [expr {[llength $w_columns] - 1}] \
>+ -column 0 \
>+ -columnspan [expr {[llength $w_columns] + 1}] \
> ]
>
> set gotoline [::linebar::new \
> $w.file_pane.out.lf $w_file \
>- -column [expr {[llength $w_columns] - 1}] \
>+ -column 0 \
>+ -columnspan [expr {[llength $w_columns] + 1}] \
> ]
>
> set w_cviewer $w.file_pane.cm.t
Looks good. Applied.
--
Pat Thoyts http://www.patthoyts.tk/
PGP fingerprint 2C 6E 98 07 2C 59 C8 97 10 CE 11 E6 04 E0 B9 DD
^ permalink raw reply
* Re: [PATCH] git-gui: guitools: add the path in the confirmation dialog for tools which needs one
From: Pat Thoyts @ 2011-10-21 22:19 UTC (permalink / raw)
To: Bert Wesarg; +Cc: git
In-Reply-To: <2fef219736a0787ed864b5c18adf31f7a4e8acda.1319139139.git.bert.wesarg@googlemail.com>
Bert Wesarg <bert.wesarg@googlemail.com> writes:
>Signed-off-by: Bert Wesarg <bert.wesarg@googlemail.com>
>---
> lib/tools.tcl | 10 ++++++++--
> 1 files changed, 8 insertions(+), 2 deletions(-)
>
>diff --git a/lib/tools.tcl b/lib/tools.tcl
>index 95e6e55..39e08f0 100644
>--- a/lib/tools.tcl
>+++ b/lib/tools.tcl
>@@ -87,8 +87,14 @@ proc tools_exec {fullname} {
> return
> }
> } elseif {[is_config_true "guitool.$fullname.confirm"]} {
>- if {[ask_popup [mc "Are you sure you want to run %s?" $fullname]] ne {yes}} {
>- return
>+ if {[is_config_true "guitool.$fullname.needsfile"]} {
>+ if {[ask_popup [mc "Are you sure you want to run %s on file \"%s\"?" $fullname $current_diff_path]] ne {yes}} {
>+ return
>+ }
>+ } else {
>+ if {[ask_popup [mc "Are you sure you want to run %s?" $fullname]] ne {yes}} {
>+ return
>+ }
> }
> }
This looks good. I modified the string there to use positional
parameters as sometimes translations need to re-order things and the
msgcat format can support this using [mc {%2$s and %1$d} $first $second]
--
Pat Thoyts http://www.patthoyts.tk/
PGP fingerprint 2C 6E 98 07 2C 59 C8 97 10 CE 11 E6 04 E0 B9 DD
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox