* Re: Git archive and trailing "/" in prefix
From: René Scharfe @ 2009-10-08 16:46 UTC (permalink / raw)
To: Sergio Callegari; +Cc: git, Junio C Hamano
In-Reply-To: <loom.20091008T172303-658@post.gmane.org>
Sergio Callegari schrieb:
> Hi!
>
> The git-archive man page indicates that if the --prefix option is passed to
> git-archive, it is compulsory to end the prefix with a "/"
>
> git archive [--format=<fmt>] [--list] [--prefix=<prefix>/] [<extra>] ...
>
> As a matter of fact, the archiver behaves quite strangely if that slash is
> missing. Files in the root of the working dir are added to the archive with
> their own name modified by the prefix and the same happens for working dir
> sub-directories. However, no file present in the sub-directories, nor
> sub-sub-directories are added.
The latter is a bug.
> I would like to know if there some reason why a trailing "/" is not added
> automatically to the prefix when it is missing and the prefix is not empty.
> Would that break anything?
The --prefix option is intended to add a string to the beginning (i.e. "to
prefix") of the name of the archive entries. I'm not sure if there's a use
case for anything else than adding a fake directory for all entries to live
in (thus requiring a trailing slash), but I also don't see why we should
disallow it.
The following patch fixes handling of prefixes without trailing slashes by
taking it out of the hands of get_pathspec() and read_tree_recursive() --
which can only handle prefixes that are path components -- and adding the
prefix later, in write_archive_entry().
Signed-off-by: Rene Scharfe <rene.scharfe@lsrfire.ath.cx>
---
archive.c | 7 ++++---
1 files changed, 4 insertions(+), 3 deletions(-)
diff --git a/archive.c b/archive.c
index 73b8e8a..0cc79d2 100644
--- a/archive.c
+++ b/archive.c
@@ -115,6 +115,7 @@ static int write_archive_entry(const unsigned char *sha1, const char *base,
strbuf_reset(&path);
strbuf_grow(&path, PATH_MAX);
+ strbuf_add(&path, args->base, args->baselen);
strbuf_add(&path, base, baselen);
strbuf_addstr(&path, filename);
path_without_prefix = path.buf + args->baselen;
@@ -187,8 +188,8 @@ int write_archive_entries(struct archiver_args *args,
git_attr_set_direction(GIT_ATTR_INDEX, &the_index);
}
- err = read_tree_recursive(args->tree, args->base, args->baselen, 0,
- args->pathspec, write_archive_entry, &context);
+ err = read_tree_recursive(args->tree, "", 0, 0, args->pathspec,
+ write_archive_entry, &context);
if (err == READ_TREE_RECURSIVE)
err = 0;
return err;
@@ -211,7 +212,7 @@ static const struct archiver *lookup_archiver(const char *name)
static void parse_pathspec_arg(const char **pathspec,
struct archiver_args *ar_args)
{
- ar_args->pathspec = get_pathspec(ar_args->base, pathspec);
+ ar_args->pathspec = get_pathspec("", pathspec);
}
static void parse_treeish_arg(const char **argv,
^ permalink raw reply related
* Re: [JGIT] patch-id
From: Shawn O. Pearce @ 2009-10-08 16:28 UTC (permalink / raw)
To: Nasser Grainawi; +Cc: Robin Rosenberg, Git Mailing List
In-Reply-To: <4AC136CC.8040300@codeaurora.org>
Nasser Grainawi <nasser@codeaurora.org> wrote:
> I'm trying to add a public getPatchId method to the jgit Patch class [...]
>
> It seems Patch does some statistical number gathering, but at no point does
> it store a 'slimmed-down' version of a patch.
It parses the patch to create FileHeader objects, one for each
file mentioned in the script. Within each FileHeader there is a
HunkHeader object, one for each hunk present in the patch. Within
each HunkHeader there is an EditList composed of Edit instances;
each Edit instance denotes a contiguous line range within that hunk.
Edit instances come in one of 3 forms:
INSERT: a run of + lines with no - lines
DELETE: a run of - lines with no + lines
REPLACE: a mixture of - and + lines
and their type is actually determined by the line numbers attached
to them. A INSERT has the same starting and ending line number on
the A side, but on the B side the ending line number is at least
one higher than the starting number. DELETE is the reverse, and
REPLACE has both ending numbers higher than the starting number.
IIRC Edit uses 0 based offsets, so line 3 is actually position 2.
These HunkHeader and Edit instances are only available on a text
patch, binary patches use a different representation for the
binary delta. Combined diff patches (--cc format) also lack these
HunkHeader/Edit instances as we don't have a generic n-way patch
parser yet.
> I had the idea to just iterate
> over the FileHeader's and get the byte buffer of each, but I don't think
> those buffers have the parsed data.
The HunkHeader and Edit instances really don't have the actual
line data available to them, they only have the line numbers.
To generate a patch ID you'd need to get the line data too.
Worse, IIRC the patch ID generation in C git favors a 3 line context.
In theory you could modify FileHeader or HunkHeader to produce
a RawText that uses the underlying byte[] returned by getBuffer()
as the backing store, but create a specialized IntList which has the
actual file line numbers mapped to the positions in the patch script.
To do that you'd need to re-walk the patch, like the toEditList()
method in HunkHeader does.
Given that RawText you could feed it through something like
DiffFormatter to create a patch with 3 lines of context, and hash
the relevant bits.
But... that seems like a lot of work.
Also, there is a class in Gerrit Code Review called EditList (not
to be confused with JGit's EditList class!) that really should be
moved back over to JGit. It has some useful routines for walking
through a patch as a series of iterations.
> Short of that, suggestions for how to go about acquiring/storing a parsed
> representation of the data with maximal existing code re-use would be
> appreciated.
I'm coming up short on suggestions right now. I'm not seeing an
easy path to this without writing a bit of code. I think you really
just need to walk the patch... :-\
--
Shawn.
^ permalink raw reply
* Re: Git archive and trailing "/" in prefix
From: Junio C Hamano @ 2009-10-08 16:26 UTC (permalink / raw)
To: Sergio Callegari; +Cc: git
In-Reply-To: <loom.20091008T172303-658@post.gmane.org>
Sergio Callegari <sergio.callegari@gmail.com> writes:
> The git-archive man page indicates that if the --prefix option is passed to
> git-archive, it is compulsory to end the prefix with a "/"
No, it does not have to.
$ git archive --prefix=v1.6.0- v1.6.0 Makefile | tar xf -
$ make -f v1.6.0-Makefile
This is consistent with the way the same --prefix option can be used with
checkout-index. e.g. to swap Makefile in work tree and in the index:
$ edit Makefile
$ git checkout-index --prefix=old- Makefile
$ git update-index Makefile
$ mv old-Makefile Makefile
These may or may not be useful examples, but this feature has been with us
for a long time. I wouldn't be surprised if removing the ability to
archive or checkout with filename prefix (not leading directory path
prefix) causes grief to existing scripts of people.
^ permalink raw reply
* Re: [PATCH] git-send-email.perl: Fold long header lines to 78 chars
From: Junio C Hamano @ 2009-10-08 16:27 UTC (permalink / raw)
To: Joe Perches; +Cc: git, Jay Soffian
In-Reply-To: <1254979690.2056.103.camel@Joe-Laptop.home>
Joe Perches <joe@perches.com> writes:
>> I do not think this hunk is correct.
>> Shouldn't we be rather repeating "RCPT TO: " for each recipient, as
>> RFC2821 4.1.1.3 says (this is an issue with the original code)?
>
> Looks like you're right.
>
> Want a new patch or will you fix both issues?
>
> I suggest using the same join as "To:" for "Cc:" and
> multiple single line "RCPT TO:"s.
Sure. Please make it so.
^ permalink raw reply
* Git archive and trailing "/" in prefix
From: Sergio Callegari @ 2009-10-08 15:35 UTC (permalink / raw)
To: git
Hi!
The git-archive man page indicates that if the --prefix option is passed to
git-archive, it is compulsory to end the prefix with a "/"
git archive [--format=<fmt>] [--list] [--prefix=<prefix>/] [<extra>] ...
As a matter of fact, the archiver behaves quite strangely if that slash is
missing. Files in the root of the working dir are added to the archive with
their own name modified by the prefix and the same happens for working dir
sub-directories. However, no file present in the sub-directories, nor
sub-sub-directories are added.
I would like to know if there some reason why a trailing "/" is not added
automatically to the prefix when it is missing and the prefix is not empty.
Would that break anything?
Thanks!
Sergio
^ permalink raw reply
* Re: [PATCH] Speedup bash completion loading
From: Kirill Smelkov @ 2009-10-08 15:10 UTC (permalink / raw)
To: Shawn O. Pearce; +Cc: Ted Pavlic, git
In-Reply-To: <20091008150206.GD9261@spearce.org>
On Thu, Oct 08, 2009 at 08:02:06AM -0700, Shawn O. Pearce wrote:
> Kirill Smelkov <kirr@mns.spb.ru> wrote:
> > diff --git a/contrib/completion/Makefile b/contrib/completion/Makefile
> > new file mode 100644
> > index 0000000..a0fbb66
> > --- /dev/null
> > +++ b/contrib/completion/Makefile
> > @@ -0,0 +1,11 @@
> > +all : git-completion.bash
> > +
> > +
> > +git-completion.bash: git-completion.bash.in git-completion.bash.generate
> > + # Generate completions for binaries we have just built
> > + PATH="$(shell pwd)/..:$$PATH" ./git-completion.bash.generate
>
> Is only one .. enough? Isn't that putting us into the contrib
> directory, and therefore not finding the 'git' we just compiled?
>
> I'm also concerned that git-completion.bash.generate requires
> bash to compile the completion for bash. IMHO, if we are building
> this code at compile time we shouldn't assume bash is available.
> What if this is a sandboxed build environment using another shell
> and /bin/bash isn't installed?
>
> I think the git-completion.bash.generate code needs to be a bit
> more sh agnostic than the completion routines themselves are.
>
> > +# pregenerated stuff (to save load time)
> > +__git_merge_strategylist=__GIT_MERGE_STRATEGYLIST
> > +__git_all_commandlist=__GIT_ALL_COMMANDLIST
> > +__git_porcelain_commandlist=__GIT_PORCELAIN_COMMANDLIST
>
> This also makes testing the completion a bit more difficult, now
> we have to build it before we can load it, making the testing cycle
> actually be:
>
> make && . git-completion.bash
>
> We probably should place a quick comment here to remind folks that
> they need to build the script in order to test it properly.
Agree with everything and thanks. Will reroll tommorow.
Кирилл
^ permalink raw reply
* Re: [PATCH] Speedup bash completion loading
From: Shawn O. Pearce @ 2009-10-08 15:02 UTC (permalink / raw)
To: Kirill Smelkov; +Cc: Ted Pavlic, git
In-Reply-To: <20091008132718.GA12161@tugrik.mns.mnsspb.ru>
Kirill Smelkov <kirr@mns.spb.ru> wrote:
> diff --git a/contrib/completion/Makefile b/contrib/completion/Makefile
> new file mode 100644
> index 0000000..a0fbb66
> --- /dev/null
> +++ b/contrib/completion/Makefile
> @@ -0,0 +1,11 @@
> +all : git-completion.bash
> +
> +
> +git-completion.bash: git-completion.bash.in git-completion.bash.generate
> + # Generate completions for binaries we have just built
> + PATH="$(shell pwd)/..:$$PATH" ./git-completion.bash.generate
Is only one .. enough? Isn't that putting us into the contrib
directory, and therefore not finding the 'git' we just compiled?
I'm also concerned that git-completion.bash.generate requires
bash to compile the completion for bash. IMHO, if we are building
this code at compile time we shouldn't assume bash is available.
What if this is a sandboxed build environment using another shell
and /bin/bash isn't installed?
I think the git-completion.bash.generate code needs to be a bit
more sh agnostic than the completion routines themselves are.
> +# pregenerated stuff (to save load time)
> +__git_merge_strategylist=__GIT_MERGE_STRATEGYLIST
> +__git_all_commandlist=__GIT_ALL_COMMANDLIST
> +__git_porcelain_commandlist=__GIT_PORCELAIN_COMMANDLIST
This also makes testing the completion a bit more difficult, now
we have to build it before we can load it, making the testing cycle
actually be:
make && . git-completion.bash
We probably should place a quick comment here to remind folks that
they need to build the script in order to test it properly.
--
Shawn.
^ permalink raw reply
* [PATCH] ls-files: make option parser keep argv[0]
From: Ben Walton @ 2009-10-08 14:20 UTC (permalink / raw)
To: gitster, git; +Cc: Ben Walton
The ls-files built-in was not asking the option parser to maintain
argv[0]. This led to the possibility of fprintf(stderr, "...", NULL).
On Solaris, this was causing a segfault. On glibc systems, printed
error messages didn't contain proper strings, but rather, "(null)":...
A trigger for this bug was: `git ls-files -i`
Signed-off-by: Ben Walton <bwalton@artsci.utoronto.ca>
---
builtin-ls-files.c | 4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/builtin-ls-files.c b/builtin-ls-files.c
index f473220..9a3705a 100644
--- a/builtin-ls-files.c
+++ b/builtin-ls-files.c
@@ -482,7 +482,7 @@ int cmd_ls_files(int argc, const char **argv, const char *prefix)
git_config(git_default_config, NULL);
argc = parse_options(argc, argv, prefix, builtin_ls_files_options,
- ls_files_usage, 0);
+ ls_files_usage, PARSE_OPT_KEEP_ARGV0);
if (show_tag || show_valid_bit) {
tag_cached = "H ";
tag_unmerged = "M ";
@@ -505,7 +505,7 @@ int cmd_ls_files(int argc, const char **argv, const char *prefix)
if (require_work_tree && !is_inside_work_tree())
setup_work_tree();
- pathspec = get_pathspec(prefix, argv);
+ pathspec = get_pathspec(prefix, argv + 1);
/* be nice with submodule paths ending in a slash */
read_cache();
--
1.6.4.4
^ permalink raw reply related
* Re: [PATCH v2] perl/Makefile.PL: detect MakeMaker versions incompatible with DESTDIR
From: Brandon Casey @ 2009-10-08 13:34 UTC (permalink / raw)
To: Johannes Sixt; +Cc: gitster, git, c, Brandon Casey
In-Reply-To: <4ACDE76C.4040307@viscovery.net>
Johannes Sixt wrote:
> Brandon Casey schrieb:
>> From: Brandon Casey <drafnel@gmail.com>
>>
>> It appears that ExtUtils::MakeMaker versions older than 6.11 do not
>> implement the DESTDIR mechanism. So add a test to the generated perl.mak
>> to detect when DESTDIR is used along with a too old ExtUtils::MakeMaker and
>> abort with a message suggesting the use of NO_PERL_MAKEMAKER.
>>
>> Signed-off-by: Brandon Casey <casey@nrlssc.navy.mil>
>> ---
>>
>>
>> This just reverses the logic in the test on $(MM_VERSION) so that the test
>> will also fail if MM_VERSION is unset. Who knows if ancient versions set
>> it. Sorry for the quick v2.
>>
>> -brandon
>>
>>
>> perl/Makefile.PL | 8 ++++++++
>> 1 files changed, 8 insertions(+), 0 deletions(-)
>>
>> diff --git a/perl/Makefile.PL b/perl/Makefile.PL
>> index 320253e..0b9deca 100644
>> --- a/perl/Makefile.PL
>> +++ b/perl/Makefile.PL
>> @@ -5,6 +5,14 @@ sub MY::postamble {
>> instlibdir:
>> @echo '$(INSTALLSITELIB)'
>>
>> +ifneq (,$(DESTDIR))
>> +ifeq (0,$(shell expr '$(MM_VERSION)' '>' 6.10))
>
> I don't think the test works as intended, because 6.2 *is* greater than
> 6.10 (aka 6.1).
Hmm... I think you're right.
-brandon
^ permalink raw reply
* Re: [PATCH] Speedup bash completion loading
From: Kirill Smelkov @ 2009-10-08 13:27 UTC (permalink / raw)
To: Shawn O. Pearce, Ted Pavlic; +Cc: git
In-Reply-To: <20091005152504.GE9261@spearce.org>
On Mon, Oct 05, 2009 at 08:25:04AM -0700, Shawn O. Pearce wrote:
> Kirill Smelkov <kirr@mns.spb.ru> wrote:
> > I've tracked down that the most time is spent warming up merge_strategy,
> > all_command & porcelain_command caches.
>
> Nak.
>
> The problem is, during completion when we modify the value the
> change doesn't persist beyond the current completion invocation.
> Thus there is no value in the cache, so every completion attempt
> which needs the list has to rerun the command to compute it.
> > Yes, my mistake.
> >
> > To avoid spawning subshell on $(__git_porcelain_commands) I could come up
> > with "caching" at the upper level, as e.g.
> >
> > @@ -2107,7 +2111,10 @@ _git ()
> > --help
> > "
> > ;;
> > - *) __gitcomp "$(__git_porcelain_commands) $(__git_aliases)" ;;
> > + *) __gitcomp "
> > + ${__git_porcelain_commandlist:=$(__git_porcelain_commands)}
> > + $(__git_aliases)
> > + " ;;
> >
> >
> > but that's ugly and not maintainable since e.g. __git_all_commands() is used in
> > several places.
On Mon, Oct 05, 2009 at 03:18:48PM -0400, Ted Pavlic wrote:
> > The other possibility is to pregenerate all these lists at git build time, but
> > are we going to do it for things under contrib/ ?
>
> IIRC, that's what StGIT does with its completion script. As a
> consequence, StGIT completion is substantially faster than git
> completion.
Ok, it turned out that in bash, functions can't return values except
through their stdout, but then we are forever with spawning
subprocesses. So I've decided to go the pregenerate-it way.
[ While at it, I've also done chmod -x to git-completion.bash -- this
script is never executed, only sourced, so it does not need to be
executable. If needed I could split it in separate patch ]
---- 8< ----
>From 4178dcc2bd1005e26e069fe32a88b9a5b164ced6 Mon Sep 17 00:00:00 2001
From: Kirill Smelkov <kirr@mns.spb.ru>
Date: Mon, 5 Oct 2009 13:36:15 +0400
Subject: [PATCH v2] Speedup bash completion loading
On my slow laptop (P3 700MHz), system-wide bash completions take too
much time to load (> 1s), and significant fraction of this time is spent
loading git-completion.bash:
$ time bash -c '. git-completion.bash' # before this patch
real 0m0.317s
user 0m0.250s
sys 0m0.060s
I've tracked down that the most time is spent warming up merge_strategy,
all_command & porcelain_command caches.
Initially I thought that since git is not used in each and every
interactive xterm, it would be perfectly ok to load completion support
with cold caches, and then load needed thing lazily.
But for me this strategy turned out to be difficult to implement in
simple and maintainable way -- bash does not provide a way to return values
from inside functions, so one will have to use e.g.
${__git_all_commandlist:=$(__git_all_commands)}
everywhere in place where $(__git_all_commands) we used before, so as
also Ted Pavlic suggested let's pregenerate everything at build time so
that we have nothing to compute at runtime when git-completion.bash
script is loaded.
The result is that loading completion is significantly faster now:
$ time bash -c '. git-completion.bash' # after this patch
real 0m0.068s
user 0m0.060s
sys 0m0.010s
Cc: Ted Pavlic <ted@tedpavlic.com>
Signed-off-by: Kirill Smelkov <kirr@mns.spb.ru>
---
contrib/completion/.gitignore | 1 +
contrib/completion/Makefile | 11 ++
contrib/completion/git-completion.bash.generate | 128 ++++++++++++++++
...{git-completion.bash => git-completion.bash.in} | 154 ++------------------
4 files changed, 155 insertions(+), 139 deletions(-)
create mode 100644 contrib/completion/.gitignore
create mode 100644 contrib/completion/Makefile
create mode 100755 contrib/completion/git-completion.bash.generate
rename contrib/completion/{git-completion.bash => git-completion.bash.in} (90%)
mode change 100755 => 100644
diff --git a/contrib/completion/.gitignore b/contrib/completion/.gitignore
new file mode 100644
index 0000000..578e6a8
--- /dev/null
+++ b/contrib/completion/.gitignore
@@ -0,0 +1 @@
+git-completion.bash
diff --git a/contrib/completion/Makefile b/contrib/completion/Makefile
new file mode 100644
index 0000000..a0fbb66
--- /dev/null
+++ b/contrib/completion/Makefile
@@ -0,0 +1,11 @@
+all : git-completion.bash
+
+
+git-completion.bash: git-completion.bash.in git-completion.bash.generate
+ # Generate completions for binaries we have just built
+ PATH="$(shell pwd)/..:$$PATH" ./git-completion.bash.generate
+
+
+clean:
+ rm -f git-completion.bash
+
diff --git a/contrib/completion/git-completion.bash.generate b/contrib/completion/git-completion.bash.generate
new file mode 100755
index 0000000..fa998dc
--- /dev/null
+++ b/contrib/completion/git-completion.bash.generate
@@ -0,0 +1,128 @@
+#!/bin/bash
+#
+# Generate bash completion for git.
+#
+# Precompute everything that can be known in advance at build time, so that
+# actual bash completion script is loaded faster.
+
+__git_merge_strategies ()
+{
+ git merge -s help 2>&1 |
+ sed -n -e '/[Aa]vailable strategies are: /,/^$/{
+ s/\.$//
+ s/.*://
+ s/^[ ]*//
+ s/[ ]*$//
+ p
+ }'
+}
+
+__git_all_commands ()
+{
+ local i IFS=" "$'\n'
+ for i in $(git help -a|egrep '^ ')
+ do
+ case $i in
+ *--*) : helper pattern;;
+ *) echo $i;;
+ esac
+ done
+}
+
+
+__git_porcelain_commands ()
+{
+ local i IFS=" "$'\n'
+ for i in "help" $(__git_all_commands)
+ do
+ case $i in
+ *--*) : helper pattern;;
+ applymbox) : ask gittus;;
+ applypatch) : ask gittus;;
+ archimport) : import;;
+ cat-file) : plumbing;;
+ check-attr) : plumbing;;
+ check-ref-format) : plumbing;;
+ checkout-index) : plumbing;;
+ commit-tree) : plumbing;;
+ count-objects) : infrequent;;
+ cvsexportcommit) : export;;
+ cvsimport) : import;;
+ cvsserver) : daemon;;
+ daemon) : daemon;;
+ diff-files) : plumbing;;
+ diff-index) : plumbing;;
+ diff-tree) : plumbing;;
+ fast-import) : import;;
+ fast-export) : export;;
+ fsck-objects) : plumbing;;
+ fetch-pack) : plumbing;;
+ fmt-merge-msg) : plumbing;;
+ for-each-ref) : plumbing;;
+ hash-object) : plumbing;;
+ http-*) : transport;;
+ index-pack) : plumbing;;
+ init-db) : deprecated;;
+ local-fetch) : plumbing;;
+ lost-found) : infrequent;;
+ ls-files) : plumbing;;
+ ls-remote) : plumbing;;
+ ls-tree) : plumbing;;
+ mailinfo) : plumbing;;
+ mailsplit) : plumbing;;
+ merge-*) : plumbing;;
+ mktree) : plumbing;;
+ mktag) : plumbing;;
+ pack-objects) : plumbing;;
+ pack-redundant) : plumbing;;
+ pack-refs) : plumbing;;
+ parse-remote) : plumbing;;
+ patch-id) : plumbing;;
+ peek-remote) : plumbing;;
+ prune) : plumbing;;
+ prune-packed) : plumbing;;
+ quiltimport) : import;;
+ read-tree) : plumbing;;
+ receive-pack) : plumbing;;
+ reflog) : plumbing;;
+ repo-config) : deprecated;;
+ rerere) : plumbing;;
+ rev-list) : plumbing;;
+ rev-parse) : plumbing;;
+ runstatus) : plumbing;;
+ sh-setup) : internal;;
+ shell) : daemon;;
+ show-ref) : plumbing;;
+ send-pack) : plumbing;;
+ show-index) : plumbing;;
+ ssh-*) : transport;;
+ stripspace) : plumbing;;
+ symbolic-ref) : plumbing;;
+ tar-tree) : deprecated;;
+ unpack-file) : plumbing;;
+ unpack-objects) : plumbing;;
+ update-index) : plumbing;;
+ update-ref) : plumbing;;
+ update-server-info) : daemon;;
+ upload-archive) : plumbing;;
+ upload-pack) : plumbing;;
+ write-tree) : plumbing;;
+ var) : infrequent;;
+ verify-pack) : infrequent;;
+ verify-tag) : plumbing;;
+ *) echo $i;;
+ esac
+ done
+}
+
+
+__git_merge_strategylist=$(__git_merge_strategies | tr '\n' ' ')
+__git_all_commandlist="$(__git_all_commands | tr '\n' ' ')"
+__git_porcelain_commandlist="$(__git_porcelain_commands | tr '\n' ' ')"
+
+
+sed -e "s/__GIT_MERGE_STRATEGYLIST/\"$__git_merge_strategylist\"/" \
+ -e "s/__GIT_ALL_COMMANDLIST/\"$__git_all_commandlist\"/" \
+ -e "s/__GIT_PORCELAIN_COMMANDLIST/\"$__git_porcelain_commandlist\"/" \
+ git-completion.bash.in > git-completion.bash
+
diff --git a/contrib/completion/git-completion.bash b/contrib/completion/git-completion.bash.in
old mode 100755
new mode 100644
similarity index 90%
rename from contrib/completion/git-completion.bash
rename to contrib/completion/git-completion.bash.in
index 88b1b3c..cf1b5fd
--- a/contrib/completion/git-completion.bash
+++ b/contrib/completion/git-completion.bash.in
@@ -21,13 +21,7 @@
# 2) Added the following line to your .bashrc:
# source ~/.git-completion.sh
#
-# 3) You may want to make sure the git executable is available
-# in your PATH before this script is sourced, as some caching
-# is performed while the script loads. If git isn't found
-# at source time then all lookups will be done on demand,
-# which may be slightly slower.
-#
-# 4) Consider changing your PS1 to also show the current branch:
+# 3) Consider changing your PS1 to also show the current branch:
# PS1='[\u@\h \W$(__git_ps1 " (%s)")]\$ '
#
# The argument to __git_ps1 will be displayed only if you
@@ -84,6 +78,14 @@ __gitdir ()
fi
}
+
+# pregenerated stuff (to save load time)
+__git_merge_strategylist=__GIT_MERGE_STRATEGYLIST
+__git_all_commandlist=__GIT_ALL_COMMANDLIST
+__git_porcelain_commandlist=__GIT_PORCELAIN_COMMANDLIST
+
+
+
# __git_ps1 accepts 0 or 1 arguments (i.e., format string)
# returns text to add to bash PS1 prompt (includes branch name)
__git_ps1 ()
@@ -324,23 +326,6 @@ __git_remotes ()
done
}
-__git_merge_strategies ()
-{
- if [ -n "${__git_merge_strategylist-}" ]; then
- echo "$__git_merge_strategylist"
- return
- fi
- git merge -s help 2>&1 |
- sed -n -e '/[Aa]vailable strategies are: /,/^$/{
- s/\.$//
- s/.*://
- s/^[ ]*//
- s/[ ]*$//
- p
- }'
-}
-__git_merge_strategylist=
-__git_merge_strategylist=$(__git_merge_strategies 2>/dev/null)
__git_complete_file ()
{
@@ -476,128 +461,19 @@ __git_complete_strategy ()
{
case "${COMP_WORDS[COMP_CWORD-1]}" in
-s|--strategy)
- __gitcomp "$(__git_merge_strategies)"
+ __gitcomp "$__git_merge_strategylist"
return 0
esac
local cur="${COMP_WORDS[COMP_CWORD]}"
case "$cur" in
--strategy=*)
- __gitcomp "$(__git_merge_strategies)" "" "${cur##--strategy=}"
+ __gitcomp "$__git_merge_strategylist" "" "${cur##--strategy=}"
return 0
;;
esac
return 1
}
-__git_all_commands ()
-{
- if [ -n "${__git_all_commandlist-}" ]; then
- echo "$__git_all_commandlist"
- return
- fi
- local i IFS=" "$'\n'
- for i in $(git help -a|egrep '^ ')
- do
- case $i in
- *--*) : helper pattern;;
- *) echo $i;;
- esac
- done
-}
-__git_all_commandlist=
-__git_all_commandlist="$(__git_all_commands 2>/dev/null)"
-
-__git_porcelain_commands ()
-{
- if [ -n "${__git_porcelain_commandlist-}" ]; then
- echo "$__git_porcelain_commandlist"
- return
- fi
- local i IFS=" "$'\n'
- for i in "help" $(__git_all_commands)
- do
- case $i in
- *--*) : helper pattern;;
- applymbox) : ask gittus;;
- applypatch) : ask gittus;;
- archimport) : import;;
- cat-file) : plumbing;;
- check-attr) : plumbing;;
- check-ref-format) : plumbing;;
- checkout-index) : plumbing;;
- commit-tree) : plumbing;;
- count-objects) : infrequent;;
- cvsexportcommit) : export;;
- cvsimport) : import;;
- cvsserver) : daemon;;
- daemon) : daemon;;
- diff-files) : plumbing;;
- diff-index) : plumbing;;
- diff-tree) : plumbing;;
- fast-import) : import;;
- fast-export) : export;;
- fsck-objects) : plumbing;;
- fetch-pack) : plumbing;;
- fmt-merge-msg) : plumbing;;
- for-each-ref) : plumbing;;
- hash-object) : plumbing;;
- http-*) : transport;;
- index-pack) : plumbing;;
- init-db) : deprecated;;
- local-fetch) : plumbing;;
- lost-found) : infrequent;;
- ls-files) : plumbing;;
- ls-remote) : plumbing;;
- ls-tree) : plumbing;;
- mailinfo) : plumbing;;
- mailsplit) : plumbing;;
- merge-*) : plumbing;;
- mktree) : plumbing;;
- mktag) : plumbing;;
- pack-objects) : plumbing;;
- pack-redundant) : plumbing;;
- pack-refs) : plumbing;;
- parse-remote) : plumbing;;
- patch-id) : plumbing;;
- peek-remote) : plumbing;;
- prune) : plumbing;;
- prune-packed) : plumbing;;
- quiltimport) : import;;
- read-tree) : plumbing;;
- receive-pack) : plumbing;;
- reflog) : plumbing;;
- repo-config) : deprecated;;
- rerere) : plumbing;;
- rev-list) : plumbing;;
- rev-parse) : plumbing;;
- runstatus) : plumbing;;
- sh-setup) : internal;;
- shell) : daemon;;
- show-ref) : plumbing;;
- send-pack) : plumbing;;
- show-index) : plumbing;;
- ssh-*) : transport;;
- stripspace) : plumbing;;
- symbolic-ref) : plumbing;;
- tar-tree) : deprecated;;
- unpack-file) : plumbing;;
- unpack-objects) : plumbing;;
- update-index) : plumbing;;
- update-ref) : plumbing;;
- update-server-info) : daemon;;
- upload-archive) : plumbing;;
- upload-pack) : plumbing;;
- write-tree) : plumbing;;
- var) : infrequent;;
- verify-pack) : infrequent;;
- verify-tag) : plumbing;;
- *) echo $i;;
- esac
- done
-}
-__git_porcelain_commandlist=
-__git_porcelain_commandlist="$(__git_porcelain_commands 2>/dev/null)"
-
__git_aliases ()
{
local i IFS=$'\n'
@@ -1077,7 +953,7 @@ _git_help ()
return
;;
esac
- __gitcomp "$(__git_all_commands)
+ __gitcomp "$__git_all_commandlist
attributes cli core-tutorial cvs-migration
diffcore gitk glossary hooks ignore modules
repository-layout tutorial tutorial-2
@@ -1423,7 +1299,7 @@ _git_config ()
return
;;
pull.twohead|pull.octopus)
- __gitcomp "$(__git_merge_strategies)"
+ __gitcomp "$__git_merge_strategylist"
return
;;
color.branch|color.diff|color.interactive|\
@@ -1524,7 +1400,7 @@ _git_config ()
pager.*)
local pfx="${cur%.*}."
cur="${cur#*.}"
- __gitcomp "$(__git_all_commands)" "$pfx" "$cur"
+ __gitcomp "$__git_all_commandlist" "$pfx" "$cur"
return
;;
remote.*.*)
@@ -2116,7 +1992,7 @@ _git ()
--help
"
;;
- *) __gitcomp "$(__git_porcelain_commands) $(__git_aliases)" ;;
+ *) __gitcomp "$__git_porcelain_commandlist $(__git_aliases)" ;;
esac
return
fi
--
1.6.5.rc2.18.g84f98.dirty
^ permalink raw reply related
* Re: [PATCH v2] perl/Makefile.PL: detect MakeMaker versions incompatible with DESTDIR
From: Johannes Sixt @ 2009-10-08 13:21 UTC (permalink / raw)
To: Brandon Casey; +Cc: gitster, git, c, Brandon Casey
In-Reply-To: <FE_WTi0YAHrCrSdGFemlb7ALatFkdSu5V7Yfb5CUgyoxfv3ZFXdFABKbT1boP7aeGWli-gJPcBA@cipher.nrlssc.navy.mil>
Brandon Casey schrieb:
> From: Brandon Casey <drafnel@gmail.com>
>
> It appears that ExtUtils::MakeMaker versions older than 6.11 do not
> implement the DESTDIR mechanism. So add a test to the generated perl.mak
> to detect when DESTDIR is used along with a too old ExtUtils::MakeMaker and
> abort with a message suggesting the use of NO_PERL_MAKEMAKER.
>
> Signed-off-by: Brandon Casey <casey@nrlssc.navy.mil>
> ---
>
>
> This just reverses the logic in the test on $(MM_VERSION) so that the test
> will also fail if MM_VERSION is unset. Who knows if ancient versions set
> it. Sorry for the quick v2.
>
> -brandon
>
>
> perl/Makefile.PL | 8 ++++++++
> 1 files changed, 8 insertions(+), 0 deletions(-)
>
> diff --git a/perl/Makefile.PL b/perl/Makefile.PL
> index 320253e..0b9deca 100644
> --- a/perl/Makefile.PL
> +++ b/perl/Makefile.PL
> @@ -5,6 +5,14 @@ sub MY::postamble {
> instlibdir:
> @echo '$(INSTALLSITELIB)'
>
> +ifneq (,$(DESTDIR))
> +ifeq (0,$(shell expr '$(MM_VERSION)' '>' 6.10))
I don't think the test works as intended, because 6.2 *is* greater than
6.10 (aka 6.1).
(Found while staring at git diff v1.6.5-rc2..v1.6.5-rc3 in a spare minute.)
> +$(error ExtUtils::MakeMaker version "$(MM_VERSION)" is older than 6.11 and so \
> + is likely incompatible with the DESTDIR mechanism. Try setting \
> + NO_PERL_MAKEMAKER=1 instead)
> +endif
> +endif
> +
> MAKE_FRAG
> }
-- Hannes
^ permalink raw reply
* Re: git log -S not finding all commits?
From: Daniel @ 2009-10-08 12:49 UTC (permalink / raw)
To: Matthieu Moy; +Cc: Andreas Ericsson, git
In-Reply-To: <vpq63aqxflu.fsf@bauges.imag.fr>
Matthieu Moy <Matthieu.Moy@grenoble-inp.fr> wrote:
> Matthieu Moy <Matthieu.Moy@grenoble-inp.fr> writes:
>
> > git log -p --format="%s\n%x00" | perl -0 -ne 'print if(/whatever-you-search/);'
>
> git log -p -z is better than my --format= indeed.
>
> --
> Matthieu Moy
> http://www-verimag.imag.fr/~moy/
>
Thanks, it's practically what I was looking for.
--
Daniel
^ permalink raw reply
* Re: git log -S not finding all commits?
From: Matthieu Moy @ 2009-10-08 11:57 UTC (permalink / raw)
To: Daniel; +Cc: Andreas Ericsson, git
In-Reply-To: <vpqbpkixgea.fsf@bauges.imag.fr>
Matthieu Moy <Matthieu.Moy@grenoble-inp.fr> writes:
> git log -p --format="%s\n%x00" | perl -0 -ne 'print if(/whatever-you-search/);'
git log -p -z is better than my --format= indeed.
--
Matthieu Moy
http://www-verimag.imag.fr/~moy/
^ permalink raw reply
* Re: git log -S not finding all commits?
From: Matthieu Moy @ 2009-10-08 11:40 UTC (permalink / raw)
To: Daniel; +Cc: Andreas Ericsson, git
In-Reply-To: <362436ca.6b5d0fc3.4acdc7e1.41b23@o2.pl>
Daniel <mjucde@o2.pl> writes:
> Andreas Ericsson <ae@op5.se> wrote:
>
>> Yes, it's the correct behaviour. -S finds only lines where what you search
>> for was added or deleted. It counts the number of occurrences of what you
>> specify in each resulting tree and only shows the commits where that number
>> changed. In your case, searching for "Free data " would have printed both
>> commits, since you first introduce that entire string and then remove it.
>
> Thanks. However, your suggestion doesn't work. It prints only commit 2. Maybe
> you meant:
>
> $ PAGER=cat git log --pickaxe-regex -S'Free data$' --oneline
>
> but that doesn't solve my problem. I want to find all commits which changed
> lines containing "Free data" (the example I posted is simplified).
>
> Seems I have to use "git log -p" and search its output using pager...
Search the ML's archives, this is a FAQ. People have proposed an
option to allow log -S to actually search the diff (much slower, but
sometimes what you really want), but AFAIK, no one wrote the code. But
I think someone posted a small perl script along the lines of
git log -p --format="%s\n%x00" | perl -0 -ne 'print if(/whatever-you-search/);'
--
Matthieu Moy
http://www-verimag.imag.fr/~moy/
^ permalink raw reply
* Re: git log -S not finding all commits?
From: Daniel @ 2009-10-08 11:07 UTC (permalink / raw)
To: Andreas Ericsson; +Cc: git
In-Reply-To: <4ACDACE6.9060509@op5.se>
Andreas Ericsson <ae@op5.se> wrote:
> Yes, it's the correct behaviour. -S finds only lines where what you search
> for was added or deleted. It counts the number of occurrences of what you
> specify in each resulting tree and only shows the commits where that number
> changed. In your case, searching for "Free data " would have printed both
> commits, since you first introduce that entire string and then remove it.
Thanks. However, your suggestion doesn't work. It prints only commit 2. Maybe
you meant:
$ PAGER=cat git log --pickaxe-regex -S'Free data$' --oneline
but that doesn't solve my problem. I want to find all commits which changed
lines containing "Free data" (the example I posted is simplified).
Seems I have to use "git log -p" and search its output using pager...
--
Daniel
^ permalink raw reply
* Re: git log -S not finding all commits?
From: Andreas Ericsson @ 2009-10-08 9:12 UTC (permalink / raw)
To: Daniel; +Cc: git
In-Reply-To: <7ae12651.522df17b.4acda0f5.21a31@o2.pl>
On 10/08/2009 10:21 AM, Daniel wrote:
> Hi,
>
> I did:
>
> $ git version
> git version 1.6.4.4
> $ mkdir a&& cd a&& git init
> $ echo "Free data"> a
> $ git add a
> $ git commit -m1
> $ echo "Free data allocated by other function"> a
> $ git commit -a -m2
> $ PAGER=cat git log -S'Free' --oneline
> 2f34241 1
>
> I would expect "git log" to show both 1 and 2 commit, but it prints only 1.
>
> Is it the correct behavior?
>
Yes, it's the correct behaviour. -S finds only lines where what you search
for was added or deleted. It counts the number of occurrences of what you
specify in each resulting tree and only shows the commits where that number
changed. In your case, searching for "Free data " would have printed both
commits, since you first introduce that entire string and then remove it.
--
Andreas Ericsson andreas.ericsson@op5.se
OP5 AB www.op5.se
Tel: +46 8-230225 Fax: +46 8-230231
Considering the successes of the wars on alcohol, poverty, drugs and
terror, I think we should give some serious thought to declaring war
on peace.
^ permalink raw reply
* Re: [Gitweb-caching][RFC] Major updates - kernel.org updated
From: Kris Shannon @ 2009-10-08 8:26 UTC (permalink / raw)
To: J.H.; +Cc: Git Mailing List
In-Reply-To: <4ACD6FED.4080308@kernel.org>
2009/10/8 J.H. <warthog9@kernel.org>:
> So I'm going to re-open the can of worms over caching again, and see what it
> would take to get this merged into mainline. Obviously a patch clean-up (my
> tree is a lot more organic than mainline) is needed, but I thought I'd try
> and get an idea of where I need to start steering all of this.
>
> - John 'Warthog9' Hawley
For everyone playing at home, I found J.H.'s tree at:
git://git.kernel.org/pub/scm/git/warthog9/gitweb.git
or Gitweb interface :)
http://git.kernel.org/?p=git/warthog9/gitweb.git
- Kris
^ permalink raw reply
* git log -S not finding all commits?
From: Daniel @ 2009-10-08 8:21 UTC (permalink / raw)
To: git
Hi,
I did:
$ git version
git version 1.6.4.4
$ mkdir a && cd a && git init
$ echo "Free data" > a
$ git add a
$ git commit -m1
$ echo "Free data allocated by other function" > a
$ git commit -a -m2
$ PAGER=cat git log -S'Free' --oneline
2f34241 1
I would expect "git log" to show both 1 and 2 commit, but it prints only 1.
Is it the correct behavior?
--
Daniel
^ permalink raw reply
* Re: [PATCH 1/3] completion: fix alias listings with newlines
From: Johannes Sixt @ 2009-10-08 8:10 UTC (permalink / raw)
To: Stephen Boyd; +Cc: Shawn O. Pearce, Junio C Hamano, git
In-Reply-To: <4ACD9C66.1080308@gmail.com>
Stephen Boyd schrieb:
> Johannes Sixt wrote:
>> OTOH, you can simply revert the hunk from 518ef8f (completion: Replace
>> config --list with --get-regexp, 2009-09-11) that applies here, or even
>> only reinstate the case statement in the loop body without changing
>> anything else.
>
> I'm not opposed to the idea, but then it wouldn't work with something like
>
> [alias]
> whowhat = "log --format="%an\nalias.broken=foo'"
>
> although that actually happening is probably rare, it can still happen.
I'd ignore this case, but *you* write the patch, *you* get to draw the line ;)
-- Hannes
^ permalink raw reply
* Re: [PATCH 1/3] completion: fix alias listings with newlines
From: Stephen Boyd @ 2009-10-08 8:01 UTC (permalink / raw)
To: Johannes Sixt; +Cc: Shawn O. Pearce, Junio C Hamano, git
In-Reply-To: <4ACD9ABC.4070809@viscovery.net>
Johannes Sixt wrote:
>
> OTOH, you can simply revert the hunk from 518ef8f (completion: Replace
> config --list with --get-regexp, 2009-09-11) that applies here, or even
> only reinstate the case statement in the loop body without changing
> anything else.
I'm not opposed to the idea, but then it wouldn't work with something like
[alias]
whowhat = "log --format="%an\nalias.broken=foo'"
although that actually happening is probably rare, it can still happen.
^ permalink raw reply
* Re: [PATCH 1/3] completion: fix alias listings with newlines
From: Johannes Sixt @ 2009-10-08 7:54 UTC (permalink / raw)
To: Stephen Boyd; +Cc: Shawn O. Pearce, Junio C Hamano, git
In-Reply-To: <4ACD961D.9080401@gmail.com>
Stephen Boyd schrieb:
> Shawn O. Pearce wrote:
>> Or a format string with a language based escape like for-each-ref
>> supports? Might make it easier to use git config in scripts if we
>> can write things like:
>>
>> git config --format='$data{%(key)}=%(value);' --perl
>
> This sounds reasonable, but also like more work ;-)
OTOH, you can simply revert the hunk from 518ef8f (completion: Replace
config --list with --get-regexp, 2009-09-11) that applies here, or even
only reinstate the case statement in the loop body without changing
anything else.
-- Hannes
^ permalink raw reply
* Re: [PATCH 1/3] completion: fix alias listings with newlines
From: Stephen Boyd @ 2009-10-08 7:34 UTC (permalink / raw)
To: Shawn O. Pearce; +Cc: Johannes Sixt, Junio C Hamano, git
In-Reply-To: <20091008042917.GX9261@spearce.org>
Shawn O. Pearce wrote:
>
> Yes, we should try to avoid spawning a process here, it fires on
> each completion attempt if I recall.
>
Ok. It looks like it fires on every completion with no command (i.e. git
<TAB><TAB>). I don't particularly like my solution anyways, and this has
existed for a long time (56fc25f maybe?) with no one noticing. A fix for
it is probably not too pressing.
I found another problem, [ARGS] and COMMAND show up in git <TAB><TAB>.
Looks like it's due to the wrapping of git's usage string.
>
> Or a format string with a language based escape like for-each-ref
> supports? Might make it easier to use git config in scripts if we
> can write things like:
>
> git config --format='$data{%(key)}=%(value);' --perl
This sounds reasonable, but also like more work ;-)
^ permalink raw reply
* Re: What's cooking in git.git (Oct 2009, #01; Wed, 07)
From: Marius Storm-Olsen @ 2009-10-08 6:58 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7viqeqjsx6.fsf@alter.siamese.dyndns.org>
Junio C Hamano said the following on 08.10.2009 08:33:
> * ef/msys-imap (2009-10-03) 7 commits
> - mingw: enable OpenSSL
> - mingw: wrap SSL_set_(w|r)fd to call _get_osfhandle
> - imap-send: provide fall-back random-source
> - imap-send: build imap-send on Windows
> - imap-send: fix compilation-error on Windows
> - imap-send: use run-command API for tunneling
> - imap-send: use separate read and write fds
Don't forget about the MSVC patch ontop of this series:
Message-ID: <18cd41840910031300i32c74b15t74eb9eee23ff8469@mail.gmail.com>
Subject: [PATCH] MSVC: Enable OpenSSL, and translate -lcrypto
--
.marius
^ permalink raw reply
* Re: What's cooking in git.git (Oct 2009, #01; Wed, 07)
From: Sverre Rabbelier @ 2009-10-08 6:49 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: spearce, git
In-Reply-To: <alpine.DEB.1.00.0910080848380.4985@pacific.mpi-cbg.de>
Heya,
On Thu, Oct 8, 2009 at 08:49, Johannes Schindelin
<Johannes.Schindelin@gmx.de> wrote:
> Shawn, last time I heard of this issue, it was stuck in your review queue.
Correct, am waiting for Shawn's decision on whether to drop options
and replace them with additional features or not.
--
Cheers,
Sverre Rabbelier
^ permalink raw reply
* Re: What's cooking in git.git (Oct 2009, #01; Wed, 07)
From: Johannes Schindelin @ 2009-10-08 6:49 UTC (permalink / raw)
To: spearce; +Cc: git
In-Reply-To: <7viqeqjsx6.fsf@alter.siamese.dyndns.org>
Hi,
On Wed, 7 Oct 2009, Junio C Hamano wrote:
> * sr/gfi-options (2009-09-06) 6 commits
> (merged to 'next' on 2009-09-07 at 5f6b0ff)
> + fast-import: test the new option command
> + fast-import: add option command
> + fast-import: test the new feature command
> + fast-import: add feature command
> + fast-import: put marks reading in it's own function
> + fast-import: put option parsing code in separate functions
> (this branch is used by jh/notes.)
>
> Ping?
Shawn, last time I heard of this issue, it was stuck in your review queue.
Ciao,
Dscho
^ 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