* Re: [PATCH] gitweb: provide a way to customize html headers
From: Junio C Hamano @ 2011-10-21 0:37 UTC (permalink / raw)
To: Lénaïc Huard; +Cc: Jakub Narebski, git
In-Reply-To: <201110210046.34679.lenaic@lhuard.fr.eu.org>
Lénaïc Huard <lenaic@lhuard.fr.eu.org> writes:
> +GITWEB_SITE_HTMLHEADER =
> GITWEB_SITE_HEADER =
> GITWEB_SITE_FOOTER =
Is it just me or does the inconsistency between the existing two variables
and this new one with a very similar name stand out like a sore something?
It might have been better if GITWEB_SITE_(HEADER|FOOTER) were named with
"_FILE" suffix, but as long as we consider/declare insert_file is the norm
and in-place inclusion of mini-string is an oddball, it is sufficient to
call this GITWEB_SITE_HTML_HEAD_STRING to avoid confusion?
Perhaps GITWEB_SITE_HEADER_STRING and GITWEB_SITE_FOOTER_STRING might turn
out to be useful in the future for in-place inclusion of mini-strings, and
when that happens, you two would thank me for this suggestion ;-)
^ permalink raw reply
* Re: shallow&single-branch clone?
From: Jeff King @ 2011-10-21 1:22 UTC (permalink / raw)
To: Norbert Nemec; +Cc: git
In-Reply-To: <4E9ED108.5020505@native-instruments.de>
On Wed, Oct 19, 2011 at 03:30:48PM +0200, Norbert Nemec wrote:
> Truncating history is done by 'git clone --depth 1', there is not way
> to restrict 'clone' to a single branch (the --branch option still
> downloads all branches and only then chooses something other than
> HEAD as active branch).
>
> The manual sequence
> git init
> git remote add -t master -f origin URL
> git checkout
> allows a clone of a single branch but offers no means to truncate history.
You can do:
git init
git remote add -t master origin URL
git fetch --depth=1
git checkout
But obviously that's not as nice as an option to clone.
> The least intrusive solution would be an additional option to clone,
> perhaps '--branch-only'.
Agreed, that would be better. We might want to make it more flexible,
like:
git clone --fetch=branch1 --fetch=branch2
and then by default choose "-b branch1" since it was mentioned first.
> More user friendly, this options should be on by default when --depth
> is set. After all: who would expect branches to be cloned when the
> history is explicitely truncated?
Yeah, that probably makes sense. If the branches are related, it's
probably not saving much, but if you have unrelated branches, it would
be a nice convenience. OTOH, how would you tell git "no, I really do
want the tip of every branch"?
-Peff
^ permalink raw reply
* git grep --no-index and absolute paths don't work?
From: Bert Wesarg @ 2011-10-21 6:34 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Git Mailing List
Hi,
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. But this does not work ether:
cd ~; git grep --no-index foo ~/.bashrc
They all fail with 'is outside repository'. Which is for itself vary
misleading, because I intentionally said --no-index.
Any input is appreciate.
Thanks.
Bert
^ permalink raw reply
* Re: [PATCH] gitweb: provide a way to customize html headers
From: Lénaïc Huard @ 2011-10-21 7:09 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Jakub Narebski, git
In-Reply-To: <7vmxcv89jl.fsf@alter.siamese.dyndns.org>
This allows web sites to add some specific html headers to the pages
generated by gitweb.
The new variable $site_html_head_string can be set to an html snippet that
will be inserted at the end of the <head> section of each page generated
by gitweb.
Signed-off-by: Lénaïc Huard <lenaic@lhuard.fr.eu.org>
---
Le vendredi 21 octobre 2011, Junio C Hamano a écrit :
> It might have been better if GITWEB_SITE_(HEADER|FOOTER) were named with
> "_FILE" suffix, but as long as we consider/declare insert_file is the norm
> and in-place inclusion of mini-string is an oddball, it is sufficient to
> call this GITWEB_SITE_HTML_HEAD_STRING to avoid confusion?
Indeed, things will be clearer like this.
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(-)
diff --git a/Documentation/gitweb.conf.txt b/Documentation/gitweb.conf.txt
index 4ca3e27..7aba497 100644
--- a/Documentation/gitweb.conf.txt
+++ b/Documentation/gitweb.conf.txt
@@ -364,6 +364,11 @@ $site_name::
+
Can be set using the `GITWEB_SITENAME` at build time. Unset by default.
+$site_html_head_string::
+ HTML snippet to be included in the <head> section of each page.
+ Can be set using `GITWEB_SITE_HTML_HEAD_STRING` at build time.
+ No default value.
+
$site_header::
Name of a file with HTML to be included at the top of each page.
Relative to the directory containing the 'gitweb.cgi' script.
diff --git a/gitweb/INSTALL b/gitweb/INSTALL
index d134ffe..6d45406 100644
--- a/gitweb/INSTALL
+++ b/gitweb/INSTALL
@@ -130,6 +130,8 @@ You can specify the following configuration variables when building GIT:
Points to an .html file which is included on the gitweb project
overview page ('projects_list' view), if it exists. Relative to
gitweb.cgi script. [Default: indextext.html]
+ * GITWEB_SITE_HTML_HEAD_STRING
+ html snippet to include in the <head> section of each page. [No default]
* GITWEB_SITE_HEADER
Filename of html text to include at top of each page. Relative to
gitweb.cgi script. [No default]
diff --git a/gitweb/Makefile b/gitweb/Makefile
index 1c85b5f..e65fc27 100644
--- a/gitweb/Makefile
+++ b/gitweb/Makefile
@@ -34,6 +34,7 @@ GITWEB_CSS = static/gitweb.css
GITWEB_LOGO = static/git-logo.png
GITWEB_FAVICON = static/git-favicon.png
GITWEB_JS = static/gitweb.js
+GITWEB_SITE_HTML_HEAD_STRING =
GITWEB_SITE_HEADER =
GITWEB_SITE_FOOTER =
HIGHLIGHT_BIN = highlight
@@ -144,6 +145,7 @@ GITWEB_REPLACE = \
-e 's|++GITWEB_LOGO++|$(GITWEB_LOGO)|g' \
-e 's|++GITWEB_FAVICON++|$(GITWEB_FAVICON)|g' \
-e 's|++GITWEB_JS++|$(GITWEB_JS)|g' \
+ -e 's|++GITWEB_SITE_HTML_HEAD_STRING++|$(GITWEB_SITE_HTML_HEAD_STRING)|g' \
-e 's|++GITWEB_SITE_HEADER++|$(GITWEB_SITE_HEADER)|g' \
-e 's|++GITWEB_SITE_FOOTER++|$(GITWEB_SITE_FOOTER)|g' \
-e 's|++HIGHLIGHT_BIN++|$(HIGHLIGHT_BIN)|g'
diff --git a/gitweb/gitweb.perl b/gitweb/gitweb.perl
index 85d64b2..fa9b83b 100755
--- a/gitweb/gitweb.perl
+++ b/gitweb/gitweb.perl
@@ -85,6 +85,8 @@ our $home_link_str = "++GITWEB_HOME_LINK_STR++";
our $site_name = "++GITWEB_SITENAME++"
|| ($ENV{'SERVER_NAME'} || "Untitled") . " Git";
+# html snippet to include in the <head> section of each page
+our $site_html_head_string = "++GITWEB_SITE_HTML_HEAD_STRING++";
# filename of html text to include at top of each page
our $site_header = "++GITWEB_SITE_HEADER++";
# html text to include at home page
@@ -3879,6 +3881,11 @@ EOF
print "<base href=\"".esc_url($base_url)."\" />\n";
}
print_header_links($status);
+
+ if (defined $site_html_head_string) {
+ print to_utf8($site_html_head_string);
+ }
+
print "</head>\n" .
"<body>\n";
diff --git a/t/gitweb-lib.sh b/t/gitweb-lib.sh
index 292753f..21d11d6 100644
--- a/t/gitweb-lib.sh
+++ b/t/gitweb-lib.sh
@@ -16,6 +16,7 @@ our \$projectroot = "$safe_pwd";
our \$project_maxdepth = 8;
our \$home_link_str = 'projects';
our \$site_name = '[localhost]';
+our \$site_html_head_string = '';
our \$site_header = '';
our \$site_footer = '';
our \$home_text = 'indextext.html';
--
1.7.7
^ permalink raw reply related
* Re: git grep --no-index and absolute paths don't work?
From: Carlos Martín Nieto @ 2011-10-21 7:09 UTC (permalink / raw)
To: Bert Wesarg; +Cc: Junio C Hamano, Git Mailing List
In-Reply-To: <CAKPyHN138OZRt_3PT5ChuTpSEuOdybnyAj8Baqr=3OD=y==jgw@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 1058 bytes --]
On Fri, 2011-10-21 at 08:34 +0200, Bert Wesarg wrote:
> Hi,
>
> 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. But this does not work ether:
The rest of the sentence reads ", not just those tracked by git" which
implies that the files tracked by git are also searched. This requires a
git repository.
>
> cd ~; git grep --no-index foo ~/.bashrc
>
> They all fail with 'is outside repository'. Which is for itself vary
> misleading, because I intentionally said --no-index.
Git is a tool that works on git repositories. Some commands may work
outside of a repository, like ls-remote when given an URL or init (for
obvious reasons) but it's not something that should be expected,
especially for commands that read files from the working tree.
Why are you trying to use git's grep command outside a repository? Why
isn't 'grep -nr foo /usr/include/' good enough?
cmn
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 490 bytes --]
^ permalink raw reply
* Links not working
From: Andy Hartley @ 2011-10-21 7:29 UTC (permalink / raw)
To: git
Hi,
I have been tying to get to the install msysGit link
https://git.wiki.kernel.org/index.php/MSysGit:InstallMSysGit
for about a week now. The page load fails after about one minute with
connection lost.
This from your http://code.google.com/p/msysgit/ main page.
FYI, Andy.
^ permalink raw reply
* Re: Links not working
From: Frans Klaver @ 2011-10-21 7:46 UTC (permalink / raw)
To: andy; +Cc: git
In-Reply-To: <686C8AC851FB48E78B12E0BB04A66FCF@DracoMain>
On Fri, Oct 21, 2011 at 9:29 AM, Andy Hartley <andy@soon.com> wrote:
> I have been tying to get to the install msysGit link
> https://git.wiki.kernel.org/index.php/MSysGit:InstallMSysGit
>
> for about a week now. The page load fails after about one minute with
> connection lost.
kernel.org has been down for over a month. It's been coming back to
life over the last week, but only very slowly. I don't know when
git.wiki.kernel.org will be available again though.
Cheers,
Frans
^ permalink raw reply
* Re: Tracking cherry picks
From: Jonathan Nieder @ 2011-10-21 9:52 UTC (permalink / raw)
To: Phillip Susi; +Cc: git, Kirill Likhodedov, Ramkumar Ramachandra
In-Reply-To: <4EA02E6C.2040608@cfl.rr.com>
Hi,
Phillip Susi wrote:
> Sometimes a bug is found and the fix needs applied to multiple
> branches. I would like to be able to list what branches the fix has been
> applied to to validate that it went in everywhere it was needed, but after
> cherry-picking the fix from master to the stable branches, the SHA1 of the
> commit is different, and so git branch --contains does not think the commit
> was applied to each of the stable branches.
If you base the fix on the oldest commit you think you might ever want to
apply it to, then you can reuse the same bugfix commit in all branches.
See gitworkflows(7) for more on this.
Hope that helps, and good luck,
Jonathan
^ permalink raw reply
* Re: Compiling on Windows
From: Erik Faye-Lund @ 2011-10-21 11:41 UTC (permalink / raw)
To: Vincent van Ravesteijn; +Cc: Philip Oakley, Andrew Ardill, Git MsysGit, git
In-Reply-To: <4EA094D2.7050807@lyx.org>
On Thu, Oct 20, 2011 at 11:38 PM, Vincent van Ravesteijn <vfr@lyx.org> wrote:
>
>>> I once wrote a little step-by-step tutorial on how to compile the native
>>> Windows Git with MSVC (Express).
>>>
>>> http://blog.vfrconsultancy.nl/#post0
>>
>> The blog post filled in a few gaps in the Msysgit README instructions
>> about where to place the various downloads described.
>
> I updated the post a little so that it actually works again. I somehow like
> to have a real native Windows compilation of Git.
Git for Windows is a "real native Windows compilation of Git". You
don't need a MSVC-compiled binary for that.
> To successfully compile Git, we also need to change
>>
>> #include <sys/resource.h>
>
> into
>>
>> #include <io.h>
>
> I have seen some communication about this in the past, but nobody cared
> enough to fix this.
>
There's been some patches dealing with this recently on the msysgit
mailing list. Look for the patches prefixed with "MSVC" in Karsten
Blees' Unicode series. They will be kicked out of the next iteration
of the Unicode series, but if you want to pick them up, clean up the
issues pointed out and re-submit them, that'd be very welcome.
> Shall I sent a patch that adds a file "compat/win32/sys/resource.h" which
> just includes "io.h" ? Or is there another more prefered way to fix this ?
I would prefer <io.h> to be included from compat/msvc.h instead,
because <io.h> isn't a <sys/resource.h> replacement.
As for the missing <sys/resource.h>, I'm not so sure. We don't have
<sys/resource.h> in msysGit either, and I personally don't like the
whole adding-stub-headers approach too much, but it does seem to be
the precedence set for the MSVC-build...
In general I'd say that no-one have worked the MSVC-support in a
while, patches would be welcome :)
^ permalink raw reply
* Re: Links not working
From: John Szakmeister @ 2011-10-21 11:52 UTC (permalink / raw)
To: andy; +Cc: git
In-Reply-To: <686C8AC851FB48E78B12E0BB04A66FCF@DracoMain>
On Fri, Oct 21, 2011 at 3:29 AM, Andy Hartley <andy@soon.com> wrote:
> Hi,
>
> I have been tying to get to the install msysGit link
> https://git.wiki.kernel.org/index.php/MSysGit:InstallMSysGit
>
> for about a week now. The page load fails after about one minute with
> connection lost.
>
> This from your http://code.google.com/p/msysgit/ main page.
You might find GitHub's page useful in the meantime:
<http://help.github.com/win-set-up-git/>
-John
^ permalink raw reply
* Re: git grep --no-index and absolute paths don't work?
From: Lars Noschinski @ 2011-10-21 11:49 UTC (permalink / raw)
To: Carlos Martín Nieto; +Cc: Bert Wesarg, Junio C Hamano, Git Mailing List
In-Reply-To: <1319180973.5352.8.camel@bee.lab.cmartin.tk>
* Carlos Martín Nieto <cmn@elego.de> [11-10-21 09:09]:
> On Fri, 2011-10-21 at 08:34 +0200, Bert Wesarg wrote:
> > 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. But this does not work ether:
>
> The rest of the sentence reads ", not just those tracked by git" which
> implies that the files tracked by git are also searched. This requires a
> git repository.
git grep --no-index works outside of git repositories (at least with
relative paths).
> > cd ~; git grep --no-index foo ~/.bashrc
> >
> > They all fail with 'is outside repository'. Which is for itself vary
> > misleading, because I intentionally said --no-index.
>
> Git is a tool that works on git repositories. Some commands may work
> outside of a repository, like ls-remote when given an URL or init (for
> obvious reasons) but it's not something that should be expected,
> especially for commands that read files from the working tree.
>
> Why are you trying to use git's grep command outside a repository? Why
> isn't 'grep -nr foo /usr/include/' good enough?
There are a few nice things about git's grep, which GNU grep does not
have:
- automatic usage of pager
- support for pathspecs (can be emulated with `find ...`)
- support for boolean combinations of regular expressions
-- Lars.
^ permalink raw reply
* Breakage in master since 6d4bb3833c
From: Michael Haggerty @ 2011-10-21 12:10 UTC (permalink / raw)
To: Junio C Hamano, git discussion list
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
ORIG=bug-6d4bb383-repo
REPO=bug-6d4bb383-clone
URL=file://$(pwd)/$ORIG
$GIT init $ORIG
cd $ORIG
$GIT config gc.auto 0
$GIT config gc.packrefs false
touch a.txt
$GIT add a.txt
$GIT commit -am 'Add file'
cd ..
mkdir $REPO
cd $REPO
$GIT init
$GIT remote add origin $URL
$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... ]
limiting output:
--max-count=<n>
--max-age=<epoch>
--min-age=<epoch>
--sparse
--no-merges
--min-parents=<n>
--no-min-parents
--max-parents=<n>
--no-max-parents
--remove-empty
--all
--branches
--tags
--remotes
--stdin
--quiet
ordering output:
--topo-order
--date-order
--reverse
formatting output:
--parents
--children
--objects | --objects-edge
--unpacked
--header | --pretty
--abbrev=<n> | --no-abbrev
--abbrev-commit
--left-right
special purpose:
--bisect
--bisect-vars
--bisect-all
error: file:///home/mhagger/self/proj/git/git/bug-6d4bb383-repo did not
send all necessary objects
=======================================================
The same error occurs if all of the steps *except* the last one are done
with a release version of git.
Michael
[1] branch "refperf" at git://github.com/mhagger/git.git
--
Michael Haggerty
mhagger@alum.mit.edu
http://softwareswirl.blogspot.com/
^ permalink raw reply
* Re: Breakage in master since 6d4bb3833c
From: SZEDER Gábor @ 2011-10-21 12:28 UTC (permalink / raw)
To: Michael Haggerty; +Cc: Junio C Hamano, git discussion list
In-Reply-To: <4EA1614D.3090202@alum.mit.edu>
Hi,
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
Best,
Gábor
^ permalink raw reply
* Re: git grep --no-index and absolute paths don't work?
From: Bert Wesarg @ 2011-10-21 12:44 UTC (permalink / raw)
To: Lars Noschinski
Cc: Carlos Martín Nieto, Junio C Hamano, Git Mailing List
In-Reply-To: <20111021114952.GA2797@lars.home.noschinski.de>
On Fri, Oct 21, 2011 at 13:49, Lars Noschinski
<lars@public.noschinski.de> wrote:
> - automatic usage of pager
> - support for pathspecs (can be emulated with `find ...`)
> - support for boolean combinations of regular expressions
- thread parallel
bert
^ permalink raw reply
* Re: [PATCH 3/3] completion: match ctags symbol names in grep patterns
From: SZEDER Gábor @ 2011-10-21 13:25 UTC (permalink / raw)
To: Jeff King; +Cc: git
In-Reply-To: <20111018050105.GC9008@sigill.intra.peff.net>
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
^ permalink raw reply
* Re: What's cooking in git.git (Oct 2011, #07; Wed, 19)
From: SZEDER Gábor @ 2011-10-21 13:47 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vk480bq5q.fsf@alter.siamese.dyndns.org>
Hi,
On Wed, Oct 19, 2011 at 02:57:37PM -0700, Junio C Hamano wrote:
> * sg/complete-refs (2011-10-15) 10 commits
> - completion: remove broken dead code from __git_heads() and __git_tags()
> - completion: fast initial completion for config 'remote.*.fetch' value
> - completion: improve ls-remote output filtering in __git_refs_remotes()
> - completion: query only refs/heads/ in __git_refs_remotes()
> - completion: support full refs from remote repositories
> - completion: improve ls-remote output filtering in __git_refs()
> - completion: make refs completion consistent for local and remote repos
> - completion: optimize refs completion
> - completion: document __gitcomp()
> - Merge branches 'tm/completion-push-set-upstream', 'tm/completion-commit-fixup-squash' and 'sg/completion' into HEAD
I think an octopus merge is unnecessary there, because
tm/completion-push-set-upstream is an independent change, and
sg/completion builds on top of tm/completion-commit-fixup-squash. So
you could just merge sg/completion into HEAD.
Best,
Gábor
^ permalink raw reply
* [PATCH v2 0/2] submodule patches
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: <1317978295-4796-2-git-send-email-rctay89@gmail.com>
Junio, this goes on top of 'fg/submodule-git-file-git-dir' (particularly
the second patch).
Changed in v2: reworded 2nd paragraph of 2nd patch, as recommended by
Jens.
Tay Ray Chuan (2):
submodule: whitespace fix
submodule::module_clone(): silence die() message from module_name()
git-submodule.sh | 8 ++++----
1 files changed, 4 insertions(+), 4 deletions(-)
--
1.7.6.msysgit.0.584.g2cbf
^ permalink raw reply
* [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
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