* 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
* What's cooking in git.git (Oct 2009, #01; Wed, 07)
From: Junio C Hamano @ 2009-10-08 6:33 UTC (permalink / raw)
To: git
Here are the topics that have been cooking. Commits prefixed with '-' are
only in 'pu' while commits prefixed with '+' are in 'next'. The ones
marked with '.' do not appear in any of the integration branches, but I am
still holding onto them.
In 1.7.0, we plan to correct handful of warts in the interfaces everybody
agrees that they were mistakes. The resulting system may not be strictly
backward compatible. Currently planeed changes are:
* refuse push to update the checked out branch in a non-bare repo by
default
Make "git push" into a repository to update the branch that is checked
out fail by default. You can countermand this default by setting a
configuration variable in the receiving repository.
http://thread.gmane.org/gmane.comp.version-control.git/107758/focus=108007
* refuse push to delete the current branch by default
Make "git push $there :$killed" to delete the branch that is pointed at
by its HEAD fail by default. You can countermand this default by
setting a configuration variable in the receiving repository.
http://thread.gmane.org/gmane.comp.version-control.git/108862/focus=108936
* git-send-email won't make deep threads by default
Many people said that by default when sending more than 2 patches the
threading git-send-email makes by default is hard to read, and they
prefer the default be one cover letter and each patch as a direct
follow-up to the cover letter. You can countermand this by setting a
configuration variable.
http://article.gmane.org/gmane.comp.version-control.git/109790
* git-status won't be "git-commit --dry-run" anymore
http://thread.gmane.org/gmane.comp.version-control.git/125989/focus=125993
* "git-diff -w --exit-code" will exit success if only differences it
found are whitespace changes that are stripped away from the output.
http://thread.gmane.org/gmane.comp.version-control.git/119731/focus=119751
We are in pre-release feature freeze. 'next' will hold topics meant for
1.6.6 and 1.7.0.
Tonight's tip of 'master' is 1.6.5-rc3.
--------------------------------------------------
[New Topics]
* ch/am-header (2009-09-25) 2 commits
(merged to 'next' on 2009-09-25 at f86e197)
+ git-am: force egrep to use correct characters set
+ git-am: fixed patch_format detection according to RFC2822
* dk/blame-el (2009-09-29) 1 commit
- git-blame.el: Change how blame information is shown.
* ef/msvc-noreturn (2009-09-30) 2 commits
(merged to 'next' on 2009-10-07 at 66137a0)
+ add NORETURN_PTR for function pointers
+ increase portability of NORETURN declarations
jk: This is the latest round and I think should be ready for at least
'next' (maybe even 'master' as it is really about the build and not about
functionality).
* 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
jk: This is from an RFC which has generated some comments. He should be
posting another round soon. 'pu' at best.
* fc/mutt-alias (2009-09-30) 1 commit
(merged to 'next' on 2009-10-07 at df7ac20)
+ send-email: fix mutt regex for grouped aliases
jk: Latest round that addressed comments. Ready for 'next' if not
'master'.
* jk/reflog-date (2009-09-24) 1 commit
(merged to 'next' on 2009-09-29 at 43d444a)
+ improve reflog date/number heuristic
* jn/gitweb-patch (2009-09-30) 1 commit
- gitweb: Do not show 'patch' link in 'commit' view for merges
jk: After some comments with Jakub, I think the code is right but he
promised a re-roll with more in the commit message.
* mr/gitweb-snapshot (2009-09-26) 2 commits
- gitweb: append short hash ids to snapshot files
- gitweb: check given hash before trying to create snapshot
jk: He posted a v5 of his series. I didn't look at it closely, but Jakub
ack'd it.
* mr/instaweb-cgid (2009-09-26) 1 commit
(merged to 'next' on 2009-09-29 at 3524604)
+ instaweb: support mod_cgid for apache2
* tf/doc-pt-br (2009-09-23) 1 commit
- Documentation: update pt-BR
The current AsciiDoc may barf on NOME and SINOPSE, as pt_BR language
definition is not widely distributed yet (it just hit the development
tree). Need to revert these headings (or change the length of the section
underlines to match the length of translated names).
* jc/pretty-lf (2009-10-04) 1 commit
- Pretty-format: %[+-]x to tweak inter-item newlines
I am not happy with this one yet. I am contemplating to introduce a new
syntax "%[magic(param)<anything>%]" to generalize expressions of this and
line wrapping features in an extensible way.
* js/log-rewrap (2008-11-10) 3 commits
. Add "%w" to pretty formats, which rewraps the commit message
- Add strbuf_add_wrapped_text() to utf8.[ch]
- print_wrapped_text(): allow hard newlines
... and the first two from this series will be useful to implement an
example magic "wrap", e.g. "%{wrap(i,j,w)%s%+b%]".
* jg/log-format-body-indent (2009-09-19) 1 commit
. git-log --format: Add %B tag with %B(x) option
I think we should redo this on top of the first two patches from
js/log-rewrap series; %B(x) is just a special case %B(x,x,0), no? If a
magic value 0 (or negative) given to wrap-width does not disable wrapping,
we probably should make it so. I merged this to 'pu' but then ejected it
because it seems to break at least t6006.
* bg/rebase-reword (2009-10-07) 1 commit
- Teach 'rebase -i' the command "reword"
* js/diff-verbose-submodule (2009-10-04) 1 commit
- Add the --submodule-summary option to the diff option family
Dscho sounded like he has some corrections after list comments, but I did
not pick up his interdiff in the middle.
--------------------------------------------------
[Stalled]
* je/send-email-no-subject (2009-08-05) 1 commit
(merged to 'next' on 2009-08-30 at b6455c2)
+ send-email: confirm on empty mail subjects
The existing tests cover the positive case (i.e. as long as the user says
"yes" to the "do you really want to send this message that lacks subject",
the message is sent) of this feature, but the feature itself needs its own
test to verify the negative case (i.e. does it correctly stop if the user
says "no"?)
* jh/cvs-helper (2009-08-18) 8 commits
- More fixes to the git-remote-cvs installation procedure
- Fix the Makefile-generated path to the git_remote_cvs package in git-remote-cvs
- Add simple selftests of git-remote-cvs functionality
- git-remote-cvs: Remote helper program for CVS repositories
- 2/2: Add Python support library for CVS remote helper
- 1/2: Add Python support library for CVS remote helper
- Basic build infrastructure for Python scripts
- Allow helpers to request marks for fast-import
(this branch uses db/vcs-helper-rest.)
Builds on db/vcs-helper. There is a re-roll planned.
* ne/rev-cache (2009-09-07) 7 commits
- support for commit grafts, slight change to general mechanism
- support for path name caching in rev-cache
- full integration of rev-cache into git, completed test suite
- administrative functions for rev-cache, start of integration into git
- support for non-commit object caching in rev-cache
- basic revision cache system, no integration or features
- man page and technical discussion for rev-cache
I merged this to 'pu' but then ejected it because it seems to break at
least t6001.
--------------------------------------------------
[Cooking]
* jl/submodule-add-noname (2009-09-22) 1 commit
- git submodule add: make the <path> parameter optional
Dscho started an interesting discussion regarding the larger workflow in
which the "submodule add" is used. I think the patch itself makes sense
but at the same time it probably makes sense to also take the <path> and
infer the <repository> as Dscho suggested, probably in "git submodule
add", not in "git add" proper, at least initially.
* jc/fix-tree-walk (2009-09-14) 9 commits
- read-tree --debug-unpack
- unpack-trees.c: look ahead in the index
- unpack-trees.c: prepare for looking ahead in the index
- traverse_trees(): handle D/F conflict case sanely
- more D/F conflict tests
- tests: move convenience regexp to match object names to test-lib.sh
- unpack_callback(): use unpack_failed() consistently
- unpack-trees: typofix
- diff-lib.c: fix misleading comments on oneway_diff()
This is my replacement for Linus's lt/maint-traverse-trees-fix patch. It
is not so much as a counter-proposal; I originally thought it might make
sense to walk the index and drive the walker to return the entries from
trees to match entries from the index, but I ended up doing pretty much
what Linus outlined --- walk the trees, and have the index walker follow
it. It turned out that the index side also needed some hairy look-ahead,
and I am only half satisfied with the current status of the series.
To fix the resolve merge regression seen in t6035, git-merge-resolve needs
to be rewritten not to use the one-path-at-a-time "git merge-index".
* jp/fetch-tag-match (2009-09-17) 1 commit
- fetch: Speed up fetch by rewriting find_non_local_tags
I did not have much energy left while dealing with the "fix-tree-walk"
series, so I just queued this without reading nor thinking about it very
much. I personally liked my version that had far smaller number of lines
changed (which means I can be fairly certain that it did not introduce any
regression), but perhaps the majorly rewritten logic this patch gives us
may be easier to follow and maintain. We'll see.
* jc/maint-blank-at-eof (2009-09-15) 0 commits.
(this branch uses jc/maint-1.6.0-blank-at-eof.)
The series does not have a commit of its own but is a preparation for
merging the original jc/1.6.0-maint-blank-at-eof topic to 'maint' and then
'master'. It is a fix for longstanding bug and 1.6.5 will not contain
this topic.
* db/vcs-helper-rest (2009-09-03) 6 commits
- Allow helpers to report in "list" command that the ref is unchanged
- Add support for "import" helper command
- Add a config option for remotes to specify a foreign vcs
- Allow programs to not depend on remotes having urls
- Allow fetch to modify refs
- Use a function to determine whether a remote is valid
(this branch is used by jh/cvs-helper.)
This holds the remainder of the db/vcs-helper topic that has already
merged for 1.6.5.
* jh/notes (2009-09-12) 13 commits
- Selftests verifying semantics when loading notes trees with various fanouts
- Teach the notes lookup code to parse notes trees with various fanout schemes
- notes.[ch] fixup: avoid old-style declaration
- Teach notes code to free its internal data structures on request.
- Add '%N'-format for pretty-printing commit notes
- Add flags to get_commit_notes() to control the format of the note string
- t3302-notes-index-expensive: Speed up create_repo()
- fast-import: Add support for importing commit notes
- Teach "-m <msg>" and "-F <file>" to "git notes edit"
- Add an expensive test for git-notes
- Speed up git notes lookup
- Add a script to edit/inspect notes
- Introduce commit notes
(this branch uses sr/gfi-options.)
Rerolled and queued.
* jn/gitweb-show-size (2009-09-07) 1 commit
- gitweb: Add 'show-sizes' feature to show blob sizes in tree view
* lt/maint-traverse-trees-fix (2009-09-06) 1 commit.
. Prepare 'traverse_trees()' for D/F conflict lookahead
Ejected from 'pu' (see jc/fix-tree-walk above).
* jc/maint-1.6.0-blank-at-eof (2009-09-14) 15 commits.
(merged to 'next' on 2009-09-15 at 9cbfa00)
+ diff -B: colour whitespace errors
+ diff.c: emit_add_line() takes only the rest of the line
+ diff.c: split emit_line() from the first char and the rest of the line
+ diff.c: shuffling code around
+ diff --whitespace: fix blank lines at end
(merged to 'next' on 2009-09-07 at 165dc3c)
+ core.whitespace: split trailing-space into blank-at-{eol,eof}
+ diff --color: color blank-at-eof
+ diff --whitespace=warn/error: fix blank-at-eof check
+ diff --whitespace=warn/error: obey blank-at-eof
+ diff.c: the builtin_diff() deals with only two-file comparison
+ apply --whitespace: warn blank but not necessarily empty lines at EOF
+ apply --whitespace=warn/error: diagnose blank at EOF
+ apply.c: split check_whitespace() into two
+ apply --whitespace=fix: detect new blank lines at eof correctly
+ apply --whitespace=fix: fix handling of blank lines at the eof
(this branch is used by jc/maint-blank-at-eof.)
This is a fix for an ancient bug (or inconsistent set of features); the
topic is based on an ancient codebase and is designed to be merged
upwards. jc/maint-blank-at-eof serves that purpose.
Will not be in 1.6.5.
* jn/gitweb-blame (2009-09-01) 5 commits
- gitweb: Minify gitweb.js if JSMIN is defined
- gitweb: Create links leading to 'blame_incremental' using JavaScript
(merged to 'next' on 2009-09-07 at 3622199)
+ gitweb: Colorize 'blame_incremental' view during processing
+ gitweb: Incremental blame (using JavaScript)
+ gitweb: Add optional "time to generate page" info in footer
Ajax-y blame.
* 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?
* nd/sparse (2009-08-20) 19 commits
- sparse checkout: inhibit empty worktree
- Add tests for sparse checkout
- read-tree: add --no-sparse-checkout to disable sparse checkout support
- unpack-trees(): ignore worktree check outside checkout area
- unpack_trees(): apply $GIT_DIR/info/sparse-checkout to the final index
- unpack-trees(): "enable" sparse checkout and load $GIT_DIR/info/sparse-checkout
- unpack-trees.c: generalize verify_* functions
- unpack-trees(): add CE_WT_REMOVE to remove on worktree alone
- Introduce "sparse checkout"
- dir.c: export excluded_1() and add_excludes_from_file_1()
- excluded_1(): support exclude files in index
- unpack-trees(): carry skip-worktree bit over in merged_entry()
- Read .gitignore from index if it is skip-worktree
- Avoid writing to buffer in add_excludes_from_file_1()
- Teach Git to respect skip-worktree bit (writing part)
- Teach Git to respect skip-worktree bit (reading part)
- Introduce "skip-worktree" bit in index, teach Git to get/set this bit
- Add test-index-version
- update-index: refactor mark_valid() in preparation for new options
--------------------------------------------------
[For 1.7.0]
* jk/1.7.0-status (2009-09-05) 5 commits
- docs: note that status configuration affects only long format
(merged to 'next' on 2009-09-07 at 8a7c563)
+ commit: support alternate status formats
+ status: add --porcelain output format
+ status: refactor format option parsing
+ status: refactor short-mode printing to its own function
(this branch uses jc/1.7.0-status.)
Gives the --short output format to post 1.7.0 "git commit --dry-run" that
is similar to that of post 1.7.0 "git status".
* jc/1.7.0-status (2009-09-05) 4 commits
(merged to 'next' on 2009-09-06 at 19d4beb)
+ status: typo fix in usage
(merged to 'next' on 2009-08-22 at b3507bb)
+ git status: not "commit --dry-run" anymore
+ git stat -s: short status output
+ git stat: the beginning of "status that is not a dry-run of commit"
(this branch is used by jk/1.7.0-status.)
With this, "git status" is no longer "git commit --dry-run".
* jc/1.7.0-send-email-no-thread-default (2009-08-22) 1 commit
(merged to 'next' on 2009-08-22 at 5106de8)
+ send-email: make --no-chain-reply-to the default
* jc/1.7.0-diff-whitespace-only-status (2009-08-30) 4 commits.
(merged to 'next' on 2009-08-30 at 0623572)
+ diff.c: fix typoes in comments
(merged to 'next' on 2009-08-27 at 81fb2bd)
+ Make test case number unique
(merged to 'next' on 2009-08-02 at 9c08420)
+ diff: Rename QUIET internal option to QUICK
+ diff: change semantics of "ignore whitespace" options
This changes exit code from "git diff --ignore-whitespace" and friends
when there is no actual output. It is a backward incompatible change, but
we could argue that it is a bugfix.
* jc/1.7.0-push-safety (2009-02-09) 2 commits
(merged to 'next' on 2009-08-02 at 38b82fe)
+ Refuse deleting the current branch via push
+ Refuse updating the current branch in a non-bare repository via push
--------------------------------------------------
[I have been too busy to purge these]
* jc/log-tz (2009-03-03) 1 commit.
- Allow --date=local --date=other-format to work as expected
Maybe some people care about this. I dunno.
* jc/mailinfo-remove-brackets (2009-07-15) 1 commit.
- mailinfo: -b option keeps [bracketed] strings that is not a [PATCH] marker
Maybe some people care about this. I dunno.
* lt/read-directory (2009-05-15) 3 commits.
. Add initial support for pathname conversion to UTF-8
. read_directory(): infrastructure for pathname character set conversion
. Add 'fill_directory()' helper function for directory traversal
* cc/reset-merge (2009-09-16) 4 commits
. reset: add test cases for "--merge-safe" option
. reset: add option "--merge-safe" to "git reset"
. reset: use "unpack_trees()" directly instead of "git read-tree"
. reset: add a few tests for "git reset --merge"
* cc/sequencer-rebase-i (2009-08-28) 15 commits
. rebase -i: use "git sequencer--helper --cherry-pick"
. sequencer: add "--cherry-pick" option to "git sequencer--helper"
. sequencer: add "do_commit()" and related functions working on "next_commit"
. pick: libify "pick_help_msg()"
. revert: libify cherry-pick and revert functionnality
. rebase -i: use "git sequencer--helper --fast-forward"
. sequencer: let "git sequencer--helper" callers set "allow_dirty"
. sequencer: add "--fast-forward" option to "git sequencer--helper"
. sequencer: add "do_fast_forward()" to perform a fast forward
. rebase -i: use "git sequencer--helper --reset-hard"
. sequencer: add "--reset-hard" option to "git sequencer--helper"
. sequencer: add "reset_almost_hard()" and related functions
. rebase -i: use "git sequencer--helper --make-patch"
. sequencer: add "make_patch" function to save a patch
. sequencer: add "builtin-sequencer--helper.c"
^ permalink raw reply
* Re: [PATCH] git-send-email.perl: Fold long header lines to 78 chars
From: Joe Perches @ 2009-10-08 5:28 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git, Jay Soffian
In-Reply-To: <7vd44yo4uz.fsf@alter.siamese.dyndns.org>
On Wed, 2009-10-07 at 22:02 -0700, Junio C Hamano wrote:
> Joe Perches <joe@perches.com> writes:
> > Some MTAs reject or filter long header lines which can
> > be generated if the cc list is only a few entries.
> > Fold long header lines to 78 chars to be more rfc compliant.
> >
> > - my $cc = join(", ", unique_email_list(@cc));
It's probably better/simpler to not use fold_header and
just do the same join as "my $to"
my $cc = join(",\n\t", unique_email_list(@cc));
> > if ($smtp_server !~ m#^/#) {
> > print "Server: $smtp_server\n";
> > print "MAIL FROM:<$raw_from>\n";
> > - print "RCPT TO:".join(',',(map { "<$_>" } @recipients))."\n";
> > + print fold_header("RCPT TO:", ",", map { "<$_>" } @recipients)."\n";
> 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.
^ permalink raw reply
* [Gitweb-caching][RFC] Major updates - kernel.org updated
From: J.H. @ 2009-10-08 4:51 UTC (permalink / raw)
To: Git Mailing List
Evening everyone,
Thought I'd give a heads up that I finally sat down and did some major
updates to my version of the gitweb caching code (as opposed to Lea's,
which I still have plans to integrate with mine in the near future).
That said this brings the base up to mainline, which is about a 2 or 3
year jump in code, it updates a number of elements in the caching engine
itself and I went ahead and ripped out the file breakout that I had
done initially.
New things known to work:
- Snapshots are fully working, and passing through the caching
engine
- Binary files now output correctly when your using blob_plain,
this is also passing correctly through the caching engine.
I'm sure there is a plethora of other things that have been fixed or broken.
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
^ permalink raw reply
* Re: [PATCH] git-send-email.perl: Fold long header lines to 78 chars
From: Junio C Hamano @ 2009-10-08 5:02 UTC (permalink / raw)
To: Joe Perches; +Cc: git, Jay Soffian
In-Reply-To: <1254759898.1799.449.camel@Joe-Laptop.home>
Joe Perches <joe@perches.com> writes:
> Some MTAs reject or filter long header lines which can
> be generated if the cc list is only a few entries.
>
> Fold long header lines to 78 chars to be more rfc compliant.
>
> Signed-off-by: Joe Perches <joe@perches.com>
>
> diff --git a/git-send-email.perl b/git-send-email.perl
> index dd821f7..cb8b48b 100755
> --- a/git-send-email.perl
> +++ b/git-send-email.perl
> @@ -835,10 +870,10 @@ sub send_message
> $gitversion = Git::version();
> }
>
> - my $cc = join(", ", unique_email_list(@cc));
> + @cc = unique_email_list(@cc);
> my $ccline = "";
> - if ($cc ne '') {
> - $ccline = "\nCc: $cc";
> + if (@cc gt 0) {
"gt"? I think you meant (@cc > 0) but you can also say "if (@cc) {" which
would most clearly convey what you want to say..
> + $ccline = fold_header("\nCc: ", ", ", @cc);
> }
> my $sanitized_sender = sanitize_address($sender);
> make_message_id() unless defined($message_id);
> @@ -976,7 +1011,7 @@ X-Mailer: git-send-email $gitversion
> if ($smtp_server !~ m#^/#) {
> print "Server: $smtp_server\n";
> print "MAIL FROM:<$raw_from>\n";
> - print "RCPT TO:".join(',',(map { "<$_>" } @recipients))."\n";
> + print fold_header("RCPT TO:", ",", map { "<$_>" } @recipients)."\n";
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)? I do not
think SMTP's "RCPT TO" command has the notion of continuation line used
for the payload (i.e. RFC 2822 Internet Message Format), and folding the
line is a new bug this patch introduces.
> } else {
> print "Sendmail: $smtp_server ".join(' ',@sendmail_parameters)."\n";
> }
^ 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