* [PATCH 3/8] imap-send: use run-command API for tunneling
From: Erik Faye-Lund @ 2009-10-09 15:04 UTC (permalink / raw)
To: git; +Cc: gitster, Erik Faye-Lund
In-Reply-To: <1255100682-13952-2-git-send-email-kusmabite@gmail.com>
Signed-off-by: Erik Faye-Lund <kusmabite@gmail.com>
---
imap-send.c | 37 ++++++++++++++++---------------------
1 files changed, 16 insertions(+), 21 deletions(-)
diff --git a/imap-send.c b/imap-send.c
index 7216453..dc3da98 100644
--- a/imap-send.c
+++ b/imap-send.c
@@ -24,6 +24,7 @@
#include "cache.h"
#include "exec_cmd.h"
+#include "run-command.h"
#ifdef NO_OPENSSL
typedef void *SSL;
#endif
@@ -940,8 +941,7 @@ static struct store *imap_open_store(struct imap_server_conf *srvc)
struct imap_store *ctx;
struct imap *imap;
char *arg, *rsp;
- int s = -1, a[2], preauth;
- pid_t pid;
+ int s = -1, preauth;
ctx = xcalloc(sizeof(*ctx), 1);
@@ -952,29 +952,24 @@ static struct store *imap_open_store(struct imap_server_conf *srvc)
/* open connection to IMAP server */
if (srvc->tunnel) {
- imap_info("Starting tunnel '%s'... ", srvc->tunnel);
+ const char *argv[4];
+ struct child_process tunnel = {0};
- if (socketpair(PF_UNIX, SOCK_STREAM, 0, a)) {
- perror("socketpair");
- exit(1);
- }
+ imap_info("Starting tunnel '%s'... ", srvc->tunnel);
- pid = fork();
- if (pid < 0)
- _exit(127);
- if (!pid) {
- if (dup2(a[0], 0) == -1 || dup2(a[0], 1) == -1)
- _exit(127);
- close(a[0]);
- close(a[1]);
- execl("/bin/sh", "sh", "-c", srvc->tunnel, NULL);
- _exit(127);
- }
+ argv[0] = "/bin/sh";
+ argv[1] = "-c";
+ argv[2] = srvc->tunnel;
+ argv[3] = NULL;
- close(a[0]);
+ tunnel.argv = argv;
+ tunnel.in = -1;
+ tunnel.out = -1;
+ if (start_command(&tunnel))
+ die("cannot start proxy %s", argv[0]);
- imap->buf.sock.fd[0] = a[1];
- imap->buf.sock.fd[1] = dup(a[1]);
+ imap->buf.sock.fd[0] = tunnel.out;
+ imap->buf.sock.fd[1] = tunnel.in;
imap_info("ok\n");
} else {
--
1.6.5.rc1.60.g41795
^ permalink raw reply related
* [PATCH 4/8] imap-send: fix compilation-error on Windows
From: Erik Faye-Lund @ 2009-10-09 15:04 UTC (permalink / raw)
To: git; +Cc: gitster, Erik Faye-Lund
In-Reply-To: <1255100682-13952-3-git-send-email-kusmabite@gmail.com>
mmsystem.h (included from windows.h) defines DRV_OK to 1. To avoid
an error due to DRV_OK redefenition, this patch undefines the old
definition (i.e the one from mmsystem.h) before defining DRV_OK.
Signed-off-by: Erik Faye-Lund <kusmabite@gmail.com>
---
imap-send.c | 4 ++++
1 files changed, 4 insertions(+), 0 deletions(-)
diff --git a/imap-send.c b/imap-send.c
index dc3da98..ed51dbf 100644
--- a/imap-send.c
+++ b/imap-send.c
@@ -94,6 +94,10 @@ struct msg_data {
unsigned int crlf:1;
};
+#ifdef DRV_OK
+#undef DRV_OK
+#endif
+
#define DRV_OK 0
#define DRV_MSG_BAD -1
#define DRV_BOX_BAD -2
--
1.6.5.rc1.60.g41795
^ permalink raw reply related
* [PATCH 8/8] MSVC: Enable OpenSSL, and translate -lcrypto
From: Erik Faye-Lund @ 2009-10-09 15:04 UTC (permalink / raw)
To: git; +Cc: gitster, Marius Storm-Olsen, Erik Faye-Lund
In-Reply-To: <1255100682-13952-7-git-send-email-kusmabite@gmail.com>
From: Marius Storm-Olsen <mstormo@gmail.com>
We don't use crypto, but rather require libeay32 and
ssleay32. handle it in both the Makefile msvc linker
script, and the buildsystem generator.
Signed-off-by: Marius Storm-Olsen <mstormo@gmail.com>
Signed-off-by: Erik Faye-Lund <kusmabite@gmail.com>
---
Makefile | 1 -
compat/vcbuild/scripts/clink.pl | 3 +++
contrib/buildsystems/engine.pl | 3 +++
3 files changed, 6 insertions(+), 1 deletions(-)
diff --git a/Makefile b/Makefile
index 8818f0f..c4b91d8 100644
--- a/Makefile
+++ b/Makefile
@@ -881,7 +881,6 @@ ifdef MSVC
GIT_VERSION := $(GIT_VERSION).MSVC
pathsep = ;
NO_PREAD = YesPlease
- NO_OPENSSL = YesPlease
NO_LIBGEN_H = YesPlease
NO_SYMLINK_HEAD = YesPlease
NO_IPV6 = YesPlease
diff --git a/compat/vcbuild/scripts/clink.pl b/compat/vcbuild/scripts/clink.pl
index 0ffd59f..fce1e24 100644
--- a/compat/vcbuild/scripts/clink.pl
+++ b/compat/vcbuild/scripts/clink.pl
@@ -29,6 +29,9 @@ while (@ARGV) {
push(@args, "zlib.lib");
} elsif ("$arg" eq "-liconv") {
push(@args, "iconv.lib");
+ } elsif ("$arg" eq "-lcrypto") {
+ push(@args, "libeay32.lib");
+ push(@args, "ssleay32.lib");
} elsif ("$arg" =~ /^-L/ && "$arg" ne "-LTCG") {
$arg =~ s/^-L/-LIBPATH:/;
push(@args, $arg);
diff --git a/contrib/buildsystems/engine.pl b/contrib/buildsystems/engine.pl
index 20bd061..d506717 100644
--- a/contrib/buildsystems/engine.pl
+++ b/contrib/buildsystems/engine.pl
@@ -315,6 +315,9 @@ sub handleLinkLine
$appout = shift @parts;
} elsif ("$part" eq "-lz") {
push(@libs, "zlib.lib");
+ } elsif ("$part" eq "-lcrypto") {
+ push(@libs, "libeay32.lib");
+ push(@libs, "ssleay32.lib");
} elsif ($part =~ /^-/) {
push(@lflags, $part);
} elsif ($part =~ /\.(a|lib)$/) {
--
1.6.5.rc1.60.g41795
^ permalink raw reply related
* [PATCH 5/8] imap-send: build imap-send on Windows
From: Erik Faye-Lund @ 2009-10-09 15:04 UTC (permalink / raw)
To: git; +Cc: gitster, Erik Faye-Lund
In-Reply-To: <1255100682-13952-4-git-send-email-kusmabite@gmail.com>
Since the POSIX-specific tunneling code has been replaced
by the run-command API (and a compile-error has been
cleaned away), we can now enable imap-send on Windows
builds.
Signed-off-by: Erik Faye-Lund <kusmabite@gmail.com>
---
Makefile | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/Makefile b/Makefile
index 12defd4..8ba789a 100644
--- a/Makefile
+++ b/Makefile
@@ -361,6 +361,7 @@ PROGRAMS += git-show-index$X
PROGRAMS += git-unpack-file$X
PROGRAMS += git-upload-pack$X
PROGRAMS += git-var$X
+PROGRAMS += git-imap-send$X
# List built-in command $C whose implementation cmd_$C() is not in
# builtin-$C.o but is linked in as part of some other command.
@@ -1056,7 +1057,6 @@ EXTLIBS += -lz
ifndef NO_POSIX_ONLY_PROGRAMS
PROGRAMS += git-daemon$X
- PROGRAMS += git-imap-send$X
endif
ifndef NO_OPENSSL
OPENSSL_LIBSSL = -lssl
--
1.6.5.rc1.60.g41795
^ permalink raw reply related
* Re: [PATCH 1/8] imap-send: remove useless uid code
From: Sverre Rabbelier @ 2009-10-09 15:21 UTC (permalink / raw)
To: Erik Faye-Lund; +Cc: git, gitster, Jeff King, Erik Faye-Lund
In-Reply-To: <1255100682-13952-1-git-send-email-kusmabite@gmail.com>
Heya,
On Fri, Oct 9, 2009 at 17:04, Erik Faye-Lund <kusmabite@googlemail.com> wrote:
Please include a cover letter for series as long as these (anything
larger than 4 should have a cover letter IMHO). Doing so makes it
easier for those that follow the series to see what changed (assuming
you write down what changed in the cover letter). Also, it makes it
easier for those that were not following the series to drop in at the
current version (assuming you provide a short summary of what the
series is about in the cover letter)..
--
Cheers,
Sverre Rabbelier
^ permalink raw reply
* Re: [PATCH] Speedup bash completion loading
From: Kirill Smelkov @ 2009-10-09 15:21 UTC (permalink / raw)
To: Shawn O. Pearce; +Cc: Ted Pavlic, git
In-Reply-To: <20091009144606.GT9261@spearce.org>
On Fri, Oct 09, 2009 at 07:46:06AM -0700, Shawn O. Pearce wrote:
> Kirill Smelkov <kirr@mns.spb.ru> wrote:
> > On Thu, Oct 08, 2009 at 08:02:06AM -0700, Shawn O. Pearce wrote:
> > > We probably should place a quick comment here to remind folks that
> > > they need to build the script in order to test it properly.
> >
> > I've added some sort of protection, so that git-completion.bash.in can't
> > be sourced at all. Is it ok?
>
> Yes, looks fine.
Thanks.
> > Subject: [PATCH 2/2] bash: make git-completion.bash.generate bash agnostic
>
> Squash this into the first patch and add the egrep change made by
> Stephen Boyd "[PATCH 1/2] completion: fix completion of git <TAB><TAB>".
While it is technically easy to do so, isn't this a bad idea to squash
semantic changes and fixes into something which should be as close as
code movement? Especially Stephen's fix?
Sure you are the maintainer, but maybe let's apply this 3 patches as
separate ones? I don't insist - this is just my 1коп.
Kirill
^ permalink raw reply
* Re: [PATCH] Speedup bash completion loading
From: Shawn O. Pearce @ 2009-10-09 15:39 UTC (permalink / raw)
To: Kirill Smelkov; +Cc: Ted Pavlic, git
In-Reply-To: <20091009152149.GA26171@tugrik.mns.mnsspb.ru>
Kirill Smelkov <kirr@mns.spb.ru> wrote:
> On Fri, Oct 09, 2009 at 07:46:06AM -0700, Shawn O. Pearce wrote:
> >
> > Squash this into the first patch and add the egrep change made by
> > Stephen Boyd "[PATCH 1/2] completion: fix completion of git <TAB><TAB>".
>
> While it is technically easy to do so, isn't this a bad idea to squash
> semantic changes and fixes into something which should be as close as
> code movement?
The ejection forces the code to build with /bin/bash, unless you
apply the trivial fixes related to IFS to make it work with dash.
As they are trivial the tiny semantic change during the code move
is just cleaner.
> Especially Stephen's fix?
I expect Junio to apply his patch first, and then yours. Since he
is changing a region you are moving, you need to account for it in
your patch, otherwise we have a conflict and/or a regression.
--
Shawn.
^ permalink raw reply
* Re: [PATCH 1/8] imap-send: remove useless uid code
From: Matt Kraai @ 2009-10-09 15:46 UTC (permalink / raw)
To: git
In-Reply-To: <1255100682-13952-1-git-send-email-kusmabite@gmail.com>
Erik Faye-Lund <kusmabite <at> googlemail.com> writes:
> Presumably this is used in isync to be able to synchronize
> mailstores multiple times without duplication. But for
> imap-send, it the values are useless; we never do anything
> with them and simply forget them at the end of the program.
On the third line of this paragraph, "it" should be removed.
^ permalink raw reply
* Re: [PATCH 4/8] imap-send: fix compilation-error on Windows
From: Matt Kraai @ 2009-10-09 15:42 UTC (permalink / raw)
To: git
In-Reply-To: <1255100682-13952-4-git-send-email-kusmabite@gmail.com>
Erik Faye-Lund <kusmabite <at> googlemail.com> writes:
> +#ifdef DRV_OK
> +#undef DRV_OK
> +#endif
> +
It shouldn't be necessary to check whether DRV_OK is defined before undefining
it; if it's not defined, undefining it will be a NOP.
^ permalink raw reply
* Re: [PATCH] Speedup bash completion loading
From: Kirill Smelkov @ 2009-10-09 16:08 UTC (permalink / raw)
To: Shawn O. Pearce; +Cc: Ted Pavlic, git
In-Reply-To: <20091009153936.GV9261@spearce.org>
On Fri, Oct 09, 2009 at 08:39:36AM -0700, Shawn O. Pearce wrote:
> Kirill Smelkov <kirr@mns.spb.ru> wrote:
> > On Fri, Oct 09, 2009 at 07:46:06AM -0700, Shawn O. Pearce wrote:
> > >
> > > Squash this into the first patch and add the egrep change made by
> > > Stephen Boyd "[PATCH 1/2] completion: fix completion of git <TAB><TAB>".
> >
> > While it is technically easy to do so, isn't this a bad idea to squash
> > semantic changes and fixes into something which should be as close as
> > code movement?
>
> The ejection forces the code to build with /bin/bash, unless you
> apply the trivial fixes related to IFS to make it work with dash.
> As they are trivial the tiny semantic change during the code move
> is just cleaner.
>
> > Especially Stephen's fix?
>
> I expect Junio to apply his patch first, and then yours. Since he
> is changing a region you are moving, you need to account for it in
> your patch, otherwise we have a conflict and/or a regression.
Now I see, OK. Here is the patch which should be applied on top of
Stephen's 1/2:
---- 8< ----
From: Kirill Smelkov <kirr@mns.spb.ru>
Date: Mon, 5 Oct 2009 13:36:15 +0400
Subject: [PATCH v4] 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
NOTE
----
As Shawn O. Pearce suggested, git-completion.bash.generate code is now
used at compile time, so we shouldn't assume bash is avalable there.
Hence, IFS tweak (not needed in the first place) in __git_all_commands()
was removed, for compile-time code to be bashism free.
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} | 161 +++-----------------
4 files changed, 162 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..90aa225
--- /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..ff64202
--- /dev/null
+++ b/contrib/completion/git-completion.bash.generate
@@ -0,0 +1,128 @@
+#!/bin/sh
+#
+# 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
+ for i in $(git help -a|egrep '^ [a-zA-Z0-9]')
+ do
+ case $i in
+ *--*) : helper pattern;;
+ *) echo $i;;
+ esac
+ done
+}
+
+
+__git_porcelain_commands ()
+{
+ local i
+ 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 652a47c..67d03c3
--- 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
@@ -60,6 +54,21 @@
# git@vger.kernel.org
#
+
+# pregenerated stuff (to save load time)
+__git_merge_strategylist=__GIT_MERGE_STRATEGYLIST
+__git_all_commandlist=__GIT_ALL_COMMANDLIST
+__git_porcelain_commandlist=__GIT_PORCELAIN_COMMANDLIST
+
+# remind folks that git-completion.bash.in can't be sourced
+case "$__git_merge_strategylist" in
+__GIT*)
+ echo "E: git-completion.bash.in can't be sourced"
+ return 1 ;;
+esac
+
+
+
case "$COMP_WORDBREAKS" in
*:*) : great ;;
*) COMP_WORDBREAKS="$COMP_WORDBREAKS:"
@@ -324,23 +333,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 +468,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 '^ [a-zA-Z0-9]')
- 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 +960,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 +1306,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 +1407,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 +1999,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 1/8] imap-send: remove useless uid code
From: Erik Faye-Lund @ 2009-10-09 16:12 UTC (permalink / raw)
To: Sverre Rabbelier; +Cc: git, gitster, Jeff King, Erik Faye-Lund
In-Reply-To: <fabb9a1e0910090821n67c86d0kb4eef1b9ff4bdff1@mail.gmail.com>
On Fri, Oct 9, 2009 at 5:21 PM, Sverre Rabbelier <srabbelier@gmail.com> wrote:
> Heya,
>
> On Fri, Oct 9, 2009 at 17:04, Erik Faye-Lund <kusmabite@googlemail.com> wrote:
>
> Please include a cover letter for series as long as these (anything
> larger than 4 should have a cover letter IMHO). Doing so makes it
> easier for those that follow the series to see what changed (assuming
> you write down what changed in the cover letter). Also, it makes it
> easier for those that were not following the series to drop in at the
> current version (assuming you provide a short summary of what the
> series is about in the cover letter)..
Doh, I'm sorry about this. Here's an added cover-letter, I hope it helps:
--->8---
Here's the 2nd iteration of my patches for Windows-compatibility in imap-send.
Patch 1-3 is about getting rid of or rewriting code with portability issues.
Patch 4 fixes a compilation error on Windows
Patch 5 enables compilation of imap-send
Patch 6-7 enables SSL-suport for mingw
Patch 8 enables imap-send and SSL for msvc
Changes in this iteration compared to the previous are as follows:
- Patch 7 has been replaced with patch 1 in the current series. All
other patches from the previous iteration has been shifted up a number
due to this.
- Patch 2 (previously 1) now has a short comment that declares it's intent.
- Patch 8 has been included
--
Erik "kusma" Faye-Lund
kusmabite@gmail.com
(+47) 986 59 656
^ permalink raw reply
* Re: [PATCH] Speedup bash completion loading
From: Shawn O. Pearce @ 2009-10-09 16:14 UTC (permalink / raw)
To: Kirill Smelkov, Junio C Hamano; +Cc: Ted Pavlic, git
In-Reply-To: <20091009160856.GA26833@tugrik.mns.mnsspb.ru>
Kirill Smelkov <kirr@mns.spb.ru> wrote:
> Now I see, OK. Here is the patch which should be applied on top of
> Stephen's 1/2:
>
> ---- 8< ----
> From: Kirill Smelkov <kirr@mns.spb.ru>
> Date: Mon, 5 Oct 2009 13:36:15 +0400
> Subject: [PATCH v4] Speedup bash completion loading
Acked-by: Shawn O. Pearce <spearce@spearce.org>
> contrib/completion/.gitignore | 1 +
> contrib/completion/Makefile | 11 ++
> contrib/completion/git-completion.bash.generate | 128 ++++++++++++++++
> ...{git-completion.bash => git-completion.bash.in} | 161 +++-----------------
> 4 files changed, 162 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
--
Shawn.
^ permalink raw reply
* Re: [PATCH 7/9] Documentation: clarify branch creation
From: Sean Estabrooks @ 2009-10-09 16:21 UTC (permalink / raw)
To: Jonathan Nieder; +Cc: git
In-Reply-To: <20091009101940.GG16558@progeny.tock>
On Fri, 9 Oct 2009 05:19:40 -0500
Jonathan Nieder <jrnieder@gmail.com> wrote:
> +In the command's second form, creates a new branch named <branchname>.
> +The branch will start out with head pointing to the commit
> +<start-point>. If no <start-point> is given, the branch will start
> +out with head pointing to the tip of the currently checked out branch,
> +or the currently checked out commit if no branch is checked out.
The first sentence here doesn't quite work, perhaps drop the "In". But
the whole thing is a bit verbose, what about just:
The command's second form creates a new branch named <branchname> which
points to the current HEAD or <start-point> if given.
> <start-point>::
> - The new branch will be created with a HEAD equal to this. It may
> - be given as a branch name, a commit-id, or a tag. If this option
> - is omitted, the current branch is assumed.
> + The new branch head will point to this commit. It may be
> + given as a branch name, a commit-id, or a tag. If this
> + option is omitted, the currently checked out branch head
> + is used, or the current commit if no branch is checked
> + out.
Maybe it's not worth worrying about, but couldn't the last sentence
be just:
If this option is omitted, the current HEAD will be used instead.
Sean
P.S. Patches 3 and 4 in this series would be better as a single patch.
^ permalink raw reply
* Git 1.6.5-rc git clone unhandled exception using http protocol
From: eduard stefan @ 2009-10-09 17:27 UTC (permalink / raw)
To: Git Mailing List
I've tried Git 1.6.5 release candidates (rc1, rc2, rc3) with msysGit,
and "git clone git://github.com/loudej/spark.git" it's working,
but "git clone http://github.com/loudej/spark.git" crashes
with an Win32 unhandled exception.
I have tried to create an empty repository and run both
"git remote-curl http://github.com/loudej/spark.git"
and "git remote-curl" , but it crashes with the same error.
How can I obtain more information about the error?
BTW, Git 1.6.4.4 is working over both protocols,
on Windows Server 2008 SP2 x86, using the same msysGit
(msysGit-fullinstall-1.6.4-preview20090729.exe).
Have a nice day,
A.
^ permalink raw reply
* Smart HTTP Protocol
From: Michael Gaffney @ 2009-10-09 17:58 UTC (permalink / raw)
To: git
What ended up being the status on this? From the last I saw, the
protocol and the fallover smart to dumb had all been worked out. It was
just that people were waiting on an implementation server side of the
protocol before the client was implemented?
-Mike
^ permalink raw reply
* Re: Smart HTTP Protocol
From: Shawn O. Pearce @ 2009-10-09 18:09 UTC (permalink / raw)
To: Michael Gaffney; +Cc: git
In-Reply-To: <4ACF79E0.5000606@gmail.com>
Michael Gaffney <mr.gaffo@gmail.com> wrote:
> What ended up being the status on this? From the last I saw, the
> protocol and the fallover smart to dumb had all been worked out. It was
> just that people were waiting on an implementation server side of the
> protocol before the client was implemented?
Uh, did you read my thread from last night at 10:30 pm called
"Return of smart HTTP" ?
Previous to this week we did not have a working server, OR a working
client, OR even a final spec.
I've started working on smart HTTP full time, and am not touching
any other project until the patches are being carried in Junio's
"next". I'm not going to rush the reviews on the list, but so long
as there is code for me to write/fix or documentation to write/fix
I'm refusing to touch another task.
I have it full implemented in JGit (client and server). I have
most of the server implemented in C Git. I'm working on the C Git
client today.
--
Shawn.
^ permalink raw reply
* feature request/proposal - clone --bare, init and init --bare with descrition
From: Eugene Sajine @ 2009-10-09 18:24 UTC (permalink / raw)
To: git; +Cc: Eugene Sajine
Hi,
here is the use case:
I'm migrating a project from CVS. I'm geting a git repo from git
cvsimport. Now I have to create a bare copy of it and put it on the
server so gitweb will see it.
Currently i have to do:
$ git clone --bare repo repo.git
I would like to be able to do
$ git clone --bare repo repo.git -d "this is my super-duper project"
So, the message goes directly to the description file.
Same thing with init or init --bare
I should have a possibility to do
$ git init --bare -d "this is my super-duper project"
What do you think?
Thanks,
Eugene
^ permalink raw reply
* Re: [PATCH 7/9] Documentation: clarify branch creation
From: Jonathan Nieder @ 2009-10-09 18:34 UTC (permalink / raw)
To: Sean Estabrooks; +Cc: git
In-Reply-To: <BLU0-SMTP425A9541141B09D790814EAECB0@phx.gbl>
Sean Estabrooks wrote:
> On Fri, 9 Oct 2009 05:19:40 -0500
> Jonathan Nieder <jrnieder@gmail.com> wrote:
>
> > +In the command's second form, creates a new branch named <branchname>.
> > +The branch will start out with head pointing to the commit
> > +<start-point>. If no <start-point> is given, the branch will start
> > +out with head pointing to the tip of the currently checked out branch,
> > +or the currently checked out commit if no branch is checked out.
>
> The first sentence here doesn't quite work, perhaps drop the "In". But
> the whole thing is a bit verbose, what about just:
>
> The command's second form creates a new branch named <branchname> which
> points to the current HEAD or <start-point> if given.
Makes sense. I modified this slightly to “new branch head” since the
branch itself does not point to anything.
> > <start-point>::
> > - The new branch will be created with a HEAD equal to this. It may
> > - be given as a branch name, a commit-id, or a tag. If this option
> > - is omitted, the current branch is assumed.
> > + The new branch head will point to this commit. It may be
> > + given as a branch name, a commit-id, or a tag. If this
> > + option is omitted, the currently checked out branch head
> > + is used, or the current commit if no branch is checked
> > + out.
>
> Maybe it's not worth worrying about, but couldn't the last sentence
> be just:
>
> If this option is omitted, the current HEAD will be used instead.
That sounds better, thanks. The reader that does not know what HEAD is
probably needs to read the relevant section of the user manual for other
reasons anyway.
So this page should probably point to the what-is-a-branch section of
the User's Manual. Maybe something like this?
-- %< --
Subject: Documentation: clarify branch creation
The documentation seems to assume that the starting point for a new
branch is the tip of an existing (ordinary) branch, but that is not
the most common case. More often, "git branch" is used to begin
a branch from a remote-tracking branch, a tag, or an interesting
commit (e.g. origin/pu^2). Clarify the language so it can apply
to these cases. Thanks to Sean Estabrooks for the wording.
Also add a pointer to the user's manual for the bewildered.
Signed-off-by: Jonathan Nieder <jrnieder@gmail.com>
---
Documentation/git-branch.txt | 16 ++++++++--------
1 files changed, 8 insertions(+), 8 deletions(-)
diff --git a/Documentation/git-branch.txt b/Documentation/git-branch.txt
index e8b32a2..f766b4d 100644
--- a/Documentation/git-branch.txt
+++ b/Documentation/git-branch.txt
@@ -30,10 +30,8 @@ commit) will be listed. With `--no-merged` only branches not merged into
the named commit will be listed. If the <commit> argument is missing it
defaults to 'HEAD' (i.e. the tip of the current branch).
-In the command's second form, a new branch named <branchname> will be created.
-It will start out with a head equal to the one given as <start-point>.
-If no <start-point> is given, the branch will be created with a head
-equal to that of the currently checked out branch.
+The command's second form creates a new branch head named <branchname>
+which points to the current 'HEAD', or <start-point> if given.
Note that this will create the new branch, but it will not switch the
working tree to it; use "git checkout <newbranch>" to switch to the
@@ -149,9 +147,9 @@ start-point is either a local or remote branch.
may restrict the characters allowed in a branch name.
<start-point>::
- The new branch will be created with a HEAD equal to this. It may
- be given as a branch name, a commit-id, or a tag. If this option
- is omitted, the current branch is assumed.
+ The new branch head will point to this commit. It may be
+ given as a branch name, a commit-id, or a tag. If this
+ option is omitted, the current HEAD will be used instead.
<oldbranch>::
The name of an existing branch to rename.
@@ -216,7 +214,9 @@ SEE ALSO
--------
linkgit:git-check-ref-format[1],
linkgit:git-fetch[1],
-linkgit:git-remote[1].
+linkgit:git-remote[1],
+link:user-manual.html#what-is-a-branch[``Understanding history: What is
+a branch?''] in the Git User's Manual.
Author
------
--
1.6.5.rc1.199.g596ec
^ permalink raw reply related
* [PATCH 1/2] t/test-lib.sh: support Korn shell by converting GIT_EXIT_OK to GIT_EXIT_CODE
From: Brandon Casey @ 2009-10-09 18:39 UTC (permalink / raw)
To: git; +Cc: drizzd, peff, Brandon Casey
From: Brandon Casey <drafnel@gmail.com>
Commit 6e7b5aaf introduced the concept of GIT_EXIT_OK as a way to indicate
to die(), the exit handler, whether the exit was initiated by the test
harness, or whether it was unexpected. die() expects $? to contain the
value passed to exit(), and when GIT_EXIT_OK is set, die() calls exit with
the value in $?. This works as expected when using the Bash shell. For
the Korn shell, $? has the value of the last executed statement _before_
the call to exit. If that statement completed successfully, then die()
would incorrectly exit with a successful status when GIT_EXIT_OK is set.
So, rather than relying on the behavior of Bash in order to get the exit
code from $? inside die(), change GIT_EXIT_OK into GIT_EXIT_CODE, and set
it to the code that we want to exit with. This allows the test suite to
be run with the Korn shell.
Signed-off-by: Brandon Casey <casey@nrlssc.navy.mil>
---
t/test-lib.sh | 15 ++++++++-------
1 files changed, 8 insertions(+), 7 deletions(-)
diff --git a/t/test-lib.sh b/t/test-lib.sh
index f2ca536..64e793a 100644
--- a/t/test-lib.sh
+++ b/t/test-lib.sh
@@ -150,7 +150,7 @@ fi
error () {
say_color error "error: $*"
- GIT_EXIT_OK=t
+ GIT_EXIT_CODE=1
exit 1
}
@@ -183,16 +183,16 @@ test_success=0
die () {
code=$?
- if test -n "$GIT_EXIT_OK"
+ if test -n "$GIT_EXIT_CODE"
then
- exit $code
+ exit $GIT_EXIT_CODE
else
echo >&5 "FATAL: Unexpected exit with code $code"
exit 1
fi
}
-GIT_EXIT_OK=
+GIT_EXIT_CODE=
trap 'die' EXIT
# The semantics of the editor variables are that of invoking
@@ -295,7 +295,7 @@ test_failure_ () {
say_color error "FAIL $test_count: $1"
shift
echo "$@" | sed -e 's/^/ /'
- test "$immediate" = "" || { GIT_EXIT_OK=t; exit 1; }
+ test "$immediate" = "" || { GIT_EXIT_CODE=1; exit 1; }
}
test_known_broken_ok_ () {
@@ -508,7 +508,6 @@ test_create_repo () {
}
test_done () {
- GIT_EXIT_OK=t
test_results_dir="$TEST_DIRECTORY/test-results"
mkdir -p "$test_results_dir"
test_results_path="$test_results_dir/${0%.sh}-$$"
@@ -539,9 +538,11 @@ test_done () {
cd "$(dirname "$remove_trash")" &&
rm -rf "$(basename "$remove_trash")"
+ GIT_EXIT_CODE=0
exit 0 ;;
*)
+ GIT_EXIT_CODE=1
say_color error "failed $test_failure among $msg"
exit 1 ;;
@@ -655,7 +656,7 @@ case "$test" in
esac
test ! -z "$debug" || remove_trash=$TRASH_DIRECTORY
rm -fr "$test" || {
- GIT_EXIT_OK=t
+ GIT_EXIT_CODE=1
echo >&5 "FATAL: Cannot prepare test area"
exit 1
}
--
1.6.5.rc3
^ permalink raw reply related
* [PATCH 2/2] Makefile: use the native (Korn) shell on SunOS and IRIX/IRIX64
From: Brandon Casey @ 2009-10-09 18:39 UTC (permalink / raw)
To: git; +Cc: drizzd, peff, Brandon Casey
In-Reply-To: <1eweIwf5YoFwmLPWwEFN69a2f-EUnj_kgiagVJoVQYfNQeLjlpm12U84RKxhzjh0NJv36SqO12lAX2c_x0WSgA@cipher.nrlssc.navy.mil>
From: Brandon Casey <drafnel@gmail.com>
Now that the test suite supports the Korn shell, we can use it as the
default on platforms that do not ship with Bash.
Signed-off-by: Brandon Casey <casey@nrlssc.navy.mil>
---
Makefile | 6 +++---
1 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/Makefile b/Makefile
index 629ab35..9ada196 100644
--- a/Makefile
+++ b/Makefile
@@ -726,7 +726,7 @@ endif
ifeq ($(uname_S),SunOS)
NEEDS_SOCKET = YesPlease
NEEDS_NSL = YesPlease
- SHELL_PATH = /bin/bash
+ SHELL_PATH = /usr/xpg4/bin/sh
SANE_TOOL_PATH = /usr/xpg6/bin:/usr/xpg4/bin
NO_STRCASESTR = YesPlease
NO_MEMMEM = YesPlease
@@ -850,7 +850,7 @@ ifeq ($(uname_S),IRIX)
NO_MMAP = YesPlease
NO_EXTERNAL_GREP = UnfortunatelyYes
SNPRINTF_RETURNS_BOGUS = YesPlease
- SHELL_PATH = /usr/gnu/bin/bash
+ SHELL_PATH = /bin/ksh
NEEDS_LIBGEN = YesPlease
THREADED_DELTA_SEARCH = YesPlease
endif
@@ -870,7 +870,7 @@ ifeq ($(uname_S),IRIX64)
NO_MMAP = YesPlease
NO_EXTERNAL_GREP = UnfortunatelyYes
SNPRINTF_RETURNS_BOGUS = YesPlease
- SHELL_PATH=/usr/gnu/bin/bash
+ SHELL_PATH=/bin/ksh
NEEDS_LIBGEN = YesPlease
THREADED_DELTA_SEARCH = YesPlease
endif
--
1.6.5.rc3
^ permalink raw reply related
* [PATCH 3-4/9 v2] Documentation: clarify mergeoptions description
From: Jonathan Nieder @ 2009-10-09 18:51 UTC (permalink / raw)
To: Sean Estabrooks; +Cc: git
In-Reply-To: <20091009101743.GD16558@progeny.tock>
Sounds better this way, at least to my ears. ("The syntax and
supported options of git merge" is a plural noun. "the same"
instead of "equal" sounds less technical and seems to convey
the meaning better here.)
Signed-off-by: Jonathan Nieder <jrnieder@gmail.com>
---
Sean Estabrooks wrote:
> P.S. Patches 3 and 4 in this series would be better as a single patch.
Good idea. Here's a squashed version.
Documentation/config.txt | 2 +-
Documentation/git-merge.txt | 4 ++--
2 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/Documentation/config.txt b/Documentation/config.txt
index be0b8ca..cd17814 100644
--- a/Documentation/config.txt
+++ b/Documentation/config.txt
@@ -539,7 +539,7 @@ branch.<name>.merge::
branch.<name>.mergeoptions::
Sets default options for merging into branch <name>. The syntax and
- supported options are equal to that of linkgit:git-merge[1], but
+ supported options are the same as those of linkgit:git-merge[1], but
option values containing whitespace characters are currently not
supported.
diff --git a/Documentation/git-merge.txt b/Documentation/git-merge.txt
index 354e9d9..6ffd4b0 100644
--- a/Documentation/git-merge.txt
+++ b/Documentation/git-merge.txt
@@ -50,8 +50,8 @@ include::merge-config.txt[]
branch.<name>.mergeoptions::
Sets default options for merging into branch <name>. The syntax and
- supported options are equal to that of 'git-merge', but option values
- containing whitespace characters are currently not supported.
+ supported options are the same as those of 'git-merge', but option
+ values containing whitespace characters are currently not supported.
HOW MERGE WORKS
---------------
--
1.6.5.rc1.199.g596ec
^ permalink raw reply related
* Re: [PATCH v2 (amend)] gitweb: Do not show 'patch' link for merge commits
From: Jeff King @ 2009-10-09 19:19 UTC (permalink / raw)
To: Jakub Narebski; +Cc: git, Junio Hamano
In-Reply-To: <200910091426.44976.jnareb@gmail.com>
On Fri, Oct 09, 2009 at 02:26:44PM +0200, Jakub Narebski wrote:
> Changes since v1:
> * Do not show 'patch' link for merge commits not only in 'commit'
> view, but also in 'commitdiff' view (more complete)
> * 'patch' link is shown also for root (parentless) commits; it
> works correctly thanks to passing '--root' option to git-format-patch
> (remove unnecessary restriction)
> * better commit message thanks to discussion with Jeff King
Thanks. I am not a gitweb expert, but those changes look good to me.
-Peff
^ permalink raw reply
* Re: [PATCH 1/2] t/test-lib.sh: support Korn shell by converting GIT_EXIT_OK to GIT_EXIT_CODE
From: Jonathan Nieder @ 2009-10-09 19:28 UTC (permalink / raw)
To: Brandon Casey; +Cc: git, drizzd, peff, Brandon Casey
In-Reply-To: <1eweIwf5YoFwmLPWwEFN69a2f-EUnj_kgiagVJoVQYfNQeLjlpm12U84RKxhzjh0NJv36SqO12lAX2c_x0WSgA@cipher.nrlssc.navy.mil>
Brandon Casey wrote:
> So, rather than relying on the behavior of Bash in order to get the exit
> code from $? inside die(), change GIT_EXIT_OK into GIT_EXIT_CODE, and set
> it to the code that we want to exit with. This allows the test suite to
> be run with the Korn shell.
>
> Signed-off-by: Brandon Casey <casey@nrlssc.navy.mil>
Sounds like a good idea. A few thoughts:
start_httpd() from lib-httpd.sh uses a similar pattern:
lib-httpd.sh:96: trap 'code=$?; stop_httpd; (exit $code); die' EXIT
It is probably worth changing that, too, unless GIT_TEST_HTTPD would not
work on these platforms for some other reason.
"GIT_EXIT_CODE=1; exit 1" sounds repetitive to my ear. It’s probably just
me, but if not, it might be worth adding a function like
expected_exit() {
GIT_EXIT_CODE=$1
exit "$1"
}
I’m not sure.
> diff --git a/t/test-lib.sh b/t/test-lib.sh
> index f2ca536..64e793a 100644
> --- a/t/test-lib.sh
> +++ b/t/test-lib.sh
[...]
> @@ -183,16 +183,16 @@ test_success=0
>
> die () {
> code=$?
> - if test -n "$GIT_EXIT_OK"
> + if test -n "$GIT_EXIT_CODE"
> then
> - exit $code
> + exit $GIT_EXIT_CODE
> else
> echo >&5 "FATAL: Unexpected exit with code $code"
> exit 1
> fi
> }
$code can be removed now, right?
Jonathan
^ permalink raw reply
* Re: [RFC PATCH 1/4] Document the HTTP transport protocol
From: Jakub Narebski @ 2009-10-09 19:27 UTC (permalink / raw)
To: Shawn O. Pearce; +Cc: git
In-Reply-To: <1255065768-10428-2-git-send-email-spearce@spearce.org>
"Shawn O. Pearce" <spearce@spearce.org> writes:
> + empty_list = PKT-LINE(id SP "capabilities^{}" NUL cap_list LF)
> +
> + non_empty_list = PKT-LINE(id SP name NUL cap_list LF)
> + *ref_record
> +
> + cap_list = *(SP capability) SP
Errr... are you sure? Because from examples it looks like cap_list
(capabilities list) is a list of space *separated* capabilities, while
the above requires also both leading and trailing space. Shouldn't it
be
cap_list = capability *(SP capability)
Also the format for capability is not defined; I guess only
a-z, 0-9, '-' and '_' are allowed in capability name.
BTW. is it possible to not have capability list?
> + HEX = "0".."9" | "a".."f"
Do you plan allowing also upper case letters, while server and client
SHOULD use lowercase? Because if you do, then RFC 5234 which defines
ABNF you seem to be using here has HEXDIG defined.
> + NL = <US-ASCII NUL, null (0)>
Why not NUL?
> + LF = <US-ASCII LF, linefeed (10)>
> + SP = <US-ASCII SP, horizontal-tab (9)>
^^^^^^^^^^^^^^-- o'rly?
Those are pre-defined in ABNF, e.g.
SP = %x20
> +References
> +----------
> +
> +link:http://www.ietf.org/rfc/rfc1738.txt[RFC 1738: Uniform Resource Locators (URL)]
> +link:http://www.ietf.org/rfc/rfc2616.txt[RFC 2616: Hypertext Transfer Protocol -- HTTP/1.1]
You should also reference the following RFCs:
* "RFC 5234: Augmented BNF for Syntax Specifications: ABNF"
* "RFC 2119: Key words for use in RFCs to Indicate Requirement Levels"
--
Jakub Narebski
Poland
ShadeHawk on #git
^ permalink raw reply
* Re: [RFC PATCH 1/4] Document the HTTP transport protocol
From: Jeff King @ 2009-10-09 19:50 UTC (permalink / raw)
To: Shawn O. Pearce; +Cc: git
In-Reply-To: <1255065768-10428-2-git-send-email-spearce@spearce.org>
On Thu, Oct 08, 2009 at 10:22:45PM -0700, Shawn O. Pearce wrote:
> +Servers MUST NOT require HTTP cookies for the purposes of
> +authentication or access control.
> [...]
> +Servers MUST NOT require HTTP cookies in order to function correctly.
> +Clients MAY store and forward HTTP cookies during request processing
> +as described by RFC 2616 (HTTP/1.1). Servers SHOULD ignore any
> +cookies sent by a client.
Why not? I can grant that the current git implementation probably can't
handle it, but keep in mind this is talking about the protocol and not
the implementation. And I can see it being useful for sites like github
which already have a cookie-based login. Adapting the client to handle
this case would not be too difficult (it would just mean keeping cookie
state in a file between runs, or even just pulling it out of the normal
browser's cookie store). And people whose client didn't do this would
simply get an "access denied" response code.
Is there a technical reason not to allow it?
-Peff
^ 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