* [PATCH I18N filenames v2 1/3] Add IO-wrappers for filenames encoding <local encoding> <-> UTF-8
From: Timur Sufiev @ 2009-10-28 18:01 UTC (permalink / raw)
To: git; +Cc: Timur Sufiev
The point is to make Git aware of filenames local encoding and make it
keep all filenames in UTF-8 internally. If
`i18n.filenameslocalencoding' option was set via git-config to a
correct <codepage> encoding, 2 things should be done:
1. Translate all filenames read by READDIR from <codepage> into UTF-8.
2. Translate all filenames passed to IO-routines from UTF-8 into
<codepage>.
This patch provides:
1. Routines for reencoding filenames from local encoding into UTF-8
and back (taking `i18n.filenameslocalencoding' into consideration).
2. I18N-wrappers around OPENDIR, READDIR, OPEN, FOPEN, STAT, LSTAT,
CHMOD, LINK AND UNLINK.
3. Makes `git-config' support `i18n.filenameslocalencoding' option.
Signed-off-by: Timur Sufiev <timur@iris-comp.ru>
---
Makefile | 2 +
cache.h | 1 +
config.c | 3 +
environment.c | 1 +
io-i18n.c | 231 +++++++++++++++++++++++++++++++++++++++++++++++++++++++++
io-i18n.h | 33 ++++++++
6 files changed, 271 insertions(+), 0 deletions(-)
create mode 100644 io-i18n.c
create mode 100644 io-i18n.h
diff --git a/Makefile b/Makefile
index 42b7d60..ac8e807 100644
--- a/Makefile
+++ b/Makefile
@@ -459,6 +459,7 @@ LIB_H += tree-walk.h
LIB_H += unpack-trees.h
LIB_H += userdiff.h
LIB_H += utf8.h
+LIB_H += io-i18n.h
LIB_H += wt-status.h
LIB_OBJS += abspath.o
@@ -562,6 +563,7 @@ LIB_OBJS += unpack-trees.o
LIB_OBJS += usage.o
LIB_OBJS += userdiff.o
LIB_OBJS += utf8.o
+LIB_OBJS += io-i18n.o
LIB_OBJS += walker.o
LIB_OBJS += wrapper.o
LIB_OBJS += write_or_die.o
diff --git a/cache.h b/cache.h
index 96840c7..7f19f7a 100644
--- a/cache.h
+++ b/cache.h
@@ -919,6 +919,7 @@ extern int user_ident_explicitly_given;
extern const char *git_commit_encoding;
extern const char *git_log_output_encoding;
+extern const char *git_filenames_local_encoding;
extern const char *git_mailmap_file;
/* IO helper functions */
diff --git a/config.c b/config.c
index c644061..2be6531 100644
--- a/config.c
+++ b/config.c
@@ -539,6 +539,9 @@ static int git_default_i18n_config(const char *var, const char *value)
if (!strcmp(var, "i18n.logoutputencoding"))
return git_config_string(&git_log_output_encoding, var, value);
+ if (!strcmp(var, "i18n.filenameslocalencoding"))
+ return git_config_string(&git_filenames_local_encoding, var, value);
+
/* Add other config variables here and to Documentation/config.txt. */
return 0;
}
diff --git a/environment.c b/environment.c
index 5de6837..b101f7b 100644
--- a/environment.c
+++ b/environment.c
@@ -24,6 +24,7 @@ int warn_ambiguous_refs = 1;
int repository_format_version;
const char *git_commit_encoding;
const char *git_log_output_encoding;
+const char *git_filenames_local_encoding;
int shared_repository = PERM_UMASK;
const char *apply_default_whitespace;
const char *apply_default_ignorewhitespace;
diff --git a/io-i18n.c b/io-i18n.c
new file mode 100644
index 0000000..ed88a68
--- /dev/null
+++ b/io-i18n.c
@@ -0,0 +1,231 @@
+#include <stdarg.h>
+#include <stddef.h>
+#include "utf8.h"
+#include "cache.h"
+#include "io-i18n.h"
+
+inline static int is_string_ascii(const char *str)
+{
+ int is_ascii = 1;
+
+ for (; *str && is_ascii; str++)
+ is_ascii &= isascii(*str);
+
+ return is_ascii;
+}
+
+char *filename_to_utf8(const char *filename)
+{
+ char *out;
+
+ if (is_string_ascii(filename))
+ return NULL;
+
+#ifndef NO_ICONV
+ if (git_filenames_local_encoding && !is_utf8(filename)) {
+ out = reencode_string(filename,
+ "utf-8", git_filenames_local_encoding);
+#ifdef DEBUG_I18N
+ fprintf(stderr, "Local -> UTF8 encoding: <%s> -> <%s>\n",
+ filename, out);
+#endif
+ return out;
+ } else if (git_filenames_local_encoding && is_utf8(filename)) {
+#ifdef DEBUG_I18N
+ fprintf(stderr,
+ "Filename <%s> is already utf8-encoded, doing nothing...\n",
+ filename);
+#endif
+ return NULL;
+ } else {
+#ifdef DEBUG_I18N
+ fprintf(stderr, "No local encoding set, doing nothing...\n");
+#endif
+ return NULL;
+ }
+#else /* #ifdef NO_ICONV */
+ warning("No iconv support, doing nothing...\n");
+ return NULL;
+#endif
+}
+
+char *filename_to_local(const char *filename)
+{
+ char *out;
+
+ if (is_string_ascii(filename))
+ return NULL;
+
+#ifndef NO_ICONV
+ if (git_filenames_local_encoding && is_utf8(filename)) {
+ out = reencode_string(filename,
+ git_filenames_local_encoding, "utf-8");
+#ifdef DEBUG_I18N
+ fprintf(stderr, "UTF8 -> local encoding: <%s> -> <%s>\n",
+ filename, out);
+#endif
+ return out;
+ } else if (git_filenames_local_encoding && !is_utf8(filename)) {
+#ifdef DEBUG_I18N
+ fprintf(stderr,
+ "Filename <%s> is already local-encoded, doing nothing...\n",
+ filename);
+#endif
+ return NULL;
+ } else {
+#ifdef DEBUG_I18N
+ fprintf(stderr, "No local encoding set, doing nothing...\n");
+#endif
+ return NULL;
+ }
+#else /* #ifdef NO_ICONV */
+ warning("No iconv support, doing nothing...\n");
+ return NULL;
+#endif
+}
+
+#undef stat
+int stat_i18n(const char *filename, struct stat *buf)
+{
+ int ret;
+ char *out = filename_to_local(filename);
+
+ if (out != NULL) {
+ ret = stat(out, buf);
+ free(out);
+ } else
+ ret = stat(filename, buf);
+ return ret;
+}
+
+#undef lstat
+int lstat_i18n(const char *filename, struct stat *buf)
+{
+
+ int ret;
+ char *out = filename_to_local(filename);
+
+ if (out != NULL) {
+ ret = lstat(out, buf);
+ free(out);
+ } else
+ ret = lstat(filename, buf);
+ return ret;
+}
+
+#undef link
+int link_i18n(const char *oldname, const char *newname)
+{
+ char *old_out = filename_to_local(oldname);
+ char *new_out = filename_to_local(newname);
+ int ret = link(old_out ? old_out : oldname,
+ new_out ? new_out : newname);
+
+ if (old_out)
+ free(old_out);
+ if (new_out)
+ free(new_out);
+ return ret;
+}
+
+#undef open
+int open_i18n(const char *filename, int flags, ...)
+{
+ int ret;
+ mode_t mode = 0;
+ char *out = filename_to_local(filename);
+
+ if ( flags & O_CREAT ) {
+ va_list ap;
+
+ va_start(ap, flags);
+ mode = va_arg(ap, int);
+ va_end(ap);
+ }
+
+ if (out != NULL) {
+ ret = open(out, flags, mode);
+ free(out);
+ } else
+ ret = open(filename, flags, mode);
+ return ret;
+}
+
+#undef unlink
+int unlink_i18n(const char *filename)
+{
+ char *out = filename_to_local(filename);
+ int ret;
+
+ if (out) {
+ ret = unlink(out);
+ free(out);
+ } else
+ ret = unlink(filename);
+ return ret;
+}
+
+#undef readdir
+struct dirent *readdir_i18n(DIR * dirstream)
+{
+ struct dirent *de = readdir(dirstream);
+
+ if (de) {
+ char *out = filename_to_utf8(de->d_name);
+
+ if (out) {
+ int len = strlen(out);
+ if (len >= NAME_MAX) {
+ warning("readdir_i18n: converted dir entry name length exceeds NAME_MAX and will be truncated\n");
+ len = NAME_MAX - 1;
+ }
+ memcpy(de->d_name, out, len);
+ de->d_name[len] = '\0';
+ free(out);
+ }
+ return de;
+ } else
+ return NULL;
+}
+
+#undef opendir
+DIR *opendir_i18n(const char *dirname)
+{
+ DIR *dir;
+ char *out = filename_to_local(dirname);
+
+ if (out != NULL) {
+ dir = opendir(out);
+ free(out);
+ } else
+ dir = opendir(dirname);
+ return dir;
+}
+
+#undef fopen
+FILE *fopen_i18n(const char *filename, const char *opentype)
+{
+ FILE *file;
+ char *out = filename_to_local(filename);
+
+ if (out != NULL) {
+ file = fopen(out, opentype);
+ free(out);
+ } else
+ file = fopen(filename, opentype);
+ return file;
+}
+
+#undef chmod
+int chmod_i18n(const char *filename, mode_t mode)
+{
+ int ret;
+ char *out = filename_to_local(filename);
+
+ if (out != NULL) {
+ ret = chmod(out, mode);
+ free(out);
+ } else
+ ret = chmod(filename, mode);
+ return ret;
+}
diff --git a/io-i18n.h b/io-i18n.h
new file mode 100644
index 0000000..2369d31
--- /dev/null
+++ b/io-i18n.h
@@ -0,0 +1,33 @@
+#ifndef GIT_IO_I18N_H
+#define GIT_IO_I18N_H
+
+#define _FILE_OFFSET_BITS 64
+
+#include <sys/stat.h>
+#include <dirent.h>
+#include <stdio.h>
+#include <unistd.h>
+
+char *filename_to_local (const char* filename);
+char *filename_to_utf8(const char *filename);
+int stat_i18n(const char *filename, struct stat *buf);
+int lstat_i18n(const char *filename, struct stat *buf);
+DIR* opendir_i18n(const char *dirname);
+struct dirent *readdir_i18n(DIR *dirstream);
+int open_i18n(const char *filename, int flags, ...);
+FILE *fopen_i18n(const char *filename, const char *opentype);
+int chmod_i18n(const char *filename, mode_t mode);
+int link_i18n(const char *oldname, const char *newname);
+int unlink_i18n(const char *filename);
+
+#define opendir(a) opendir_i18n(a)
+#define fopen(a, b) fopen_i18n(a, b)
+#define chmod(a, b) chmod_i18n(a, b)
+#define open open_i18n
+#define stat(a, b) stat_i18n(a, b)
+#define lstat(a, b) lstat_i18n(a, b)
+#define readdir(a) readdir_i18n(a)
+#define unlink(a) unlink_i18n(a)
+#define link(a, b) link_i18n(a, b)
+
+#endif /* GIT_IO_I18N_H */
--
1.6.5.1
^ permalink raw reply related
* Re: [PATCH 2/4] Add I18N-wrappers for low-level IO-routines
From: Timur Sufiev @ 2009-10-28 18:01 UTC (permalink / raw)
To: Jeff King; +Cc: git
In-Reply-To: <20091027210817.GA1577@sigill.intra.peff.net>
> Hmm. Two questions about this series:
>
> 1. Patch 3/4 didn't seem to make it to the list. Presumably that is
> where you actually use these routines in git? Or are they just for
> mingw?
Yes, it actually haven't made it to the list. Perhaps this was due to
patch size: it was approx. 3300 lines long (BTW, what's the message size
limit?) So I've rewritten the patch to make it more compact, using mingw
approach with macros. Subj prefix for a patch series is 'PATCH I18N
filenames v2'.
> 2. I seem to recall that Linus added a filename translation layer for
> doing much more, like handling unicode normalizations (but I
> confess I haven't looked closely at that code). Should this be part
> of that system?
I've heard nothing about that :(. Could you point me directly at Linus'
changes?
> -Peff
--
Timur Sufiev
^ permalink raw reply
* Re: [PATCH] imap-send.c: fix pointer to be const
From: Junio C Hamano @ 2009-10-28 17:56 UTC (permalink / raw)
To: Michael J Gruber; +Cc: Vietor Liu, git
In-Reply-To: <4AE8482F.7020807@drmicha.warpmail.net>
Michael J Gruber <git@drmicha.warpmail.net> writes:
> Since this is only about warnings, maybe git 1.7.0 is the right time
> frame to adjust this to the upcoming standard?
This does not look like "one group wants this way, but the others want
differently. We have to pick one and sacrifice the other because it is
impossible to have it both ways"; there is no excuse to bring up 1.7.0 for
something like this.
Doesn't inclusing "ssl.h" give us some indication whether "const" is
needed to allow us to use #if/#else/#endif in order to compile with
headers from either versions? I.e. something like...
diff --git a/imap-send.c b/imap-send.c
index 3847fd1..a199db8 100644
--- a/imap-send.c
+++ b/imap-send.c
@@ -273,7 +273,11 @@ static int ssl_socket_connect(struct imap_socket *sock, int use_tls_only, int ve
fprintf(stderr, "SSL requested but SSL support not compiled in\n");
return -1;
#else
+#if (OPENSSL_VERSION_NUMBER >= 0x1000000fL)
+ const SSL_METHOD *meth;
+#else
SSL_METHOD *meth;
+#endif
SSL_CTX *ctx;
int ret;
^ permalink raw reply related
* Re: packaging vs default pager
From: Junio C Hamano @ 2009-10-28 17:55 UTC (permalink / raw)
To: Ben Walton; +Cc: GIT List
In-Reply-To: <1256742357-sup-3798@ntdws12.chass.utoronto.ca>
Ben Walton <bwalton@artsci.utoronto.ca> writes:
> On (old) solaris systems, /usr/bin/less (typically the first less
> found) doesn't understand the default arguments (FXRS), which forces
> users to alter their environment (PATH, GIT_PAGER, LESS, etc) or have
> a local or global gitconfig before paging works as expected.
>
> Would it be completely out of line to provide a knob so that the
> fallback $pager could be set to something more specific/appropriate
> during the build?
I think that is a sensible thing to do. Something like this?
Makefile | 6 ++++++
| 6 +++++-
2 files changed, 11 insertions(+), 1 deletions(-)
diff --git a/Makefile b/Makefile
index 268aede..342d49a 100644
--- a/Makefile
+++ b/Makefile
@@ -200,6 +200,9 @@ all::
# memory allocators with the nedmalloc allocator written by Niall Douglas.
#
# Define NO_REGEX if you have no or inferior regex support in your C library.
+#
+# Define DEFAULT_PAGER to the path of a sensible pager (defaults to "less") if
+# you want to use something different.
GIT-VERSION-FILE: .FORCE-GIT-VERSION-FILE
@$(SHELL_PATH) ./GIT-VERSION-GEN
@@ -1294,6 +1297,9 @@ ifdef NO_REGEX
COMPAT_CFLAGS += -Icompat/regex
COMPAT_OBJS += compat/regex/regex.o
endif
+ifdef DEFAULT_PAGER
+ BASIC_CFLAGS += -DDEFAULT_PAGER='"$(DEFAULT_PAGER)"'
+endif
ifdef USE_NED_ALLOCATOR
COMPAT_CFLAGS += -DUSE_NED_ALLOCATOR -DOVERRIDE_STRDUP -DNDEBUG -DREPLACE_SYSTEM_ALLOCATOR -Icompat/nedmalloc
--git a/pager.c b/pager.c
index 86facec..f4c992d 100644
--- a/pager.c
+++ b/pager.c
@@ -2,6 +2,10 @@
#include "run-command.h"
#include "sigchain.h"
+#ifndef DEFAULT_PAGER
+#define DEFAULT_PAGER "less"
+#endif
+
/*
* This is split up from the rest of git so that we can do
* something different on Windows.
@@ -58,7 +62,7 @@ void setup_pager(void)
if (!pager)
pager = getenv("PAGER");
if (!pager)
- pager = "less";
+ pager = DEFAULT_PAGER;
else if (!*pager || !strcmp(pager, "cat"))
return;
^ permalink raw reply related
* [PATCH] t5540: test both smart and dumb protocols
From: Clemens Buchacher @ 2009-10-28 17:52 UTC (permalink / raw)
To: Shawn O. Pearce; +Cc: Mark Lodato, git
In-Reply-To: <20091028001737.GN10505@spearce.org>
Signed-off-by: Clemens Buchacher <drizzd@aon.at>
---
On Tue, Oct 27, 2009 at 05:17:38PM -0700, Shawn O. Pearce wrote:
> Clemens Buchacher <drizzd@aon.at> wrote:
> > Set LIB_HTTPD_GIT to enable smart HTTP tests.
>
> My concern here is we have to run the test suite twice in order to
> test HTTP support. We should only run it once, with GIT_TEST_HTTPD=1
> set and have it all run at once.
How about this? The original code is not touched except for the test
description.
Clemens
t/lib-httpd.sh | 2 +
t/t5540-http-push.sh | 160 ++-----------------------------------------------
t/test-http-push.sh | 159 +++++++++++++++++++++++++++++++++++++++++++++++++
3 files changed, 168 insertions(+), 153 deletions(-)
create mode 100755 t/test-http-push.sh
diff --git a/t/lib-httpd.sh b/t/lib-httpd.sh
index aaa0a71..cf1f1df 100644
--- a/t/lib-httpd.sh
+++ b/t/lib-httpd.sh
@@ -121,4 +121,6 @@ stop_httpd() {
"$LIB_HTTPD_PATH" -d "$HTTPD_ROOT_PATH" \
-f "$TEST_PATH/apache.conf" $HTTPD_PARA -k stop
+
+ rm -f "$HTTPD_ROOT_PATH/modules"
}
diff --git a/t/t5540-http-push.sh b/t/t5540-http-push.sh
index 049e129..a156f37 100755
--- a/t/t5540-http-push.sh
+++ b/t/t5540-http-push.sh
@@ -1,155 +1,9 @@
#!/bin/sh
-#
-# Copyright (c) 2008 Clemens Buchacher <drizzd@aon.at>
-#
-test_description='test http-push
-
-This test runs various sanity checks on http-push.'
-
-. ./test-lib.sh
-
-ROOT_PATH="$PWD"
-if test -z "$LIB_HTTPD_GIT"
-then
- LIB_HTTPD_DAV=t
-fi
-LIB_HTTPD_PORT=${LIB_HTTPD_PORT-'5540'}
-
-if git http-push > /dev/null 2>&1 || [ $? -eq 128 ]
-then
- say "skipping test, USE_CURL_MULTI is not defined"
- test_done
-fi
-
-. "$TEST_DIRECTORY"/lib-httpd.sh
-start_httpd
-
-test_expect_success 'setup remote repository' '
- cd "$ROOT_PATH" &&
- mkdir test_repo &&
- cd test_repo &&
- git init &&
- : >path1 &&
- git add path1 &&
- test_tick &&
- git commit -m initial &&
- cd - &&
- git clone --bare test_repo test_repo.git &&
- cd test_repo.git &&
- ORIG_HEAD=$(git rev-parse --verify HEAD) &&
- if test -n "$LIB_HTTPD_GIT"
- then
- git config http.receivepack true
- else
- git --bare update-server-info &&
- mv hooks/post-update.sample hooks/post-update
- fi &&
- cd - &&
- mv test_repo.git "$HTTPD_GIT_PATH"
-'
-
-test_expect_success 'clone remote repository' '
- cd "$ROOT_PATH" &&
- git clone $HTTPD_GIT_URL/test_repo.git test_repo_clone
-'
-
-test_expect_success 'push to remote repository with packed refs' '
- cd "$ROOT_PATH"/test_repo_clone &&
- : >path2 &&
- git add path2 &&
- test_tick &&
- git commit -m path2 &&
- HEAD=$(git rev-parse --verify HEAD) &&
- git push &&
- (cd "$HTTPD_GIT_PATH"/test_repo.git &&
- test $HEAD = $(git rev-parse --verify HEAD))
-'
-
-test_expect_success 'push already up-to-date' '
- git push
-'
-
-test_expect_success 'push to remote repository with unpacked refs' '
- (cd "$HTTPD_GIT_PATH"/test_repo.git &&
- rm packed-refs &&
- git update-ref refs/heads/master $ORIG_HEAD &&
- git --bare update-server-info) &&
- git push &&
- (cd "$HTTPD_GIT_PATH"/test_repo.git &&
- test $HEAD = $(git rev-parse --verify HEAD))
-'
-
-test_expect_success 'http-push fetches unpacked objects' '
- cp -R "$HTTPD_GIT_PATH"/test_repo.git \
- "$HTTPD_GIT_PATH"/test_repo_unpacked.git &&
-
- git clone $HTTPD_GIT_URL/test_repo_unpacked.git \
- "$ROOT_PATH"/fetch_unpacked &&
-
- # By reset, we force git to retrieve the object
- (cd "$ROOT_PATH"/fetch_unpacked &&
- git reset --hard HEAD^ &&
- git remote rm origin &&
- git reflog expire --expire=0 --all &&
- git prune &&
- git push -f -v $HTTPD_GIT_URL/test_repo_unpacked.git master)
-'
-
-test_expect_success 'http-push fetches packed objects' '
- cp -R "$HTTPD_GIT_PATH"/test_repo.git \
- "$HTTPD_GIT_PATH"/test_repo_packed.git &&
-
- git clone $HTTPD_GIT_URL/test_repo_packed.git \
- "$ROOT_PATH"/test_repo_clone_packed &&
-
- (cd "$HTTPD_GIT_PATH"/test_repo_packed.git &&
- git --bare repack &&
- git --bare prune-packed) &&
-
- # By reset, we force git to retrieve the packed object
- (cd "$ROOT_PATH"/test_repo_clone_packed &&
- git reset --hard HEAD^ &&
- git remote rm origin &&
- git reflog expire --expire=0 --all &&
- git prune &&
- git push -f -v $HTTPD_GIT_URL/test_repo_packed.git master)
-'
-
-test_expect_success 'create and delete remote branch' '
- cd "$ROOT_PATH"/test_repo_clone &&
- git checkout -b dev &&
- : >path3 &&
- git add path3 &&
- test_tick &&
- git commit -m dev &&
- git push origin dev &&
- git fetch &&
- git push origin :dev &&
- git fetch &&
- test_must_fail git show-ref --verify refs/remotes/origin/dev
-'
-
-test -n "$LIB_HTTPD_GIT" ||
-test_expect_success 'MKCOL sends directory names with trailing slashes' '
-
- ! grep "\"MKCOL.*[^/] HTTP/[^ ]*\"" < "$HTTPD_ROOT_PATH"/access.log
-
-'
-
-x1="[0-9a-f]"
-x2="$x1$x1"
-x5="$x1$x1$x1$x1$x1"
-x38="$x5$x5$x5$x5$x5$x5$x5$x1$x1$x1"
-x40="$x38$x2"
-
-test -n "$LIB_HTTPD_GIT" ||
-test_expect_success 'PUT and MOVE sends object to URLs with SHA-1 hash suffix' '
- sed -e "s/PUT /OP /" -e "s/MOVE /OP /" "$HTTPD_ROOT_PATH"/access.log |
- grep -e "\"OP .*/objects/$x2/${x38}_$x40 HTTP/[.0-9]*\" 20[0-9] "
-
-'
-
-stop_httpd
-
-test_done
+LIB_HTTPD_GIT=t
+export LIB_HTTPD_GIT
+./test-http-push.sh $@
+sleep 1
+LIB_HTTPD_GIT=
+export LIB_HTTPD_GIT
+./test-http-push.sh $@
diff --git a/t/test-http-push.sh b/t/test-http-push.sh
new file mode 100755
index 0000000..c557541
--- /dev/null
+++ b/t/test-http-push.sh
@@ -0,0 +1,159 @@
+#!/bin/sh
+
+if test -n "$LIB_HTTPD_GIT"
+then
+ protocol=smart
+else
+ protocol=dumb
+fi
+
+test_description="test http-push ($protocol)
+
+This test runs various sanity checks on http-push."
+
+. ./test-lib.sh
+
+ROOT_PATH="$PWD"
+if test -z "$LIB_HTTPD_GIT"
+then
+ LIB_HTTPD_DAV=t
+fi
+LIB_HTTPD_PORT=${LIB_HTTPD_PORT-'5540'}
+
+if git http-push > /dev/null 2>&1 || [ $? -eq 128 ]
+then
+ say "skipping test, USE_CURL_MULTI is not defined"
+ test_done
+fi
+
+. "$TEST_DIRECTORY"/lib-httpd.sh
+start_httpd
+
+test_expect_success 'setup remote repository' '
+ cd "$ROOT_PATH" &&
+ mkdir test_repo &&
+ cd test_repo &&
+ git init &&
+ : >path1 &&
+ git add path1 &&
+ test_tick &&
+ git commit -m initial &&
+ cd - &&
+ git clone --bare test_repo test_repo.git &&
+ cd test_repo.git &&
+ ORIG_HEAD=$(git rev-parse --verify HEAD) &&
+ if test -n "$LIB_HTTPD_GIT"
+ then
+ git config http.receivepack true
+ else
+ git --bare update-server-info &&
+ mv hooks/post-update.sample hooks/post-update
+ fi &&
+ cd - &&
+ mv test_repo.git "$HTTPD_GIT_PATH"
+'
+
+test_expect_success 'clone remote repository' '
+ cd "$ROOT_PATH" &&
+ git clone $HTTPD_GIT_URL/test_repo.git test_repo_clone
+'
+
+test_expect_success 'push to remote repository with packed refs' '
+ cd "$ROOT_PATH"/test_repo_clone &&
+ : >path2 &&
+ git add path2 &&
+ test_tick &&
+ git commit -m path2 &&
+ HEAD=$(git rev-parse --verify HEAD) &&
+ git push &&
+ (cd "$HTTPD_GIT_PATH"/test_repo.git &&
+ test $HEAD = $(git rev-parse --verify HEAD))
+'
+
+test_expect_success 'push already up-to-date' '
+ git push
+'
+
+test_expect_success 'push to remote repository with unpacked refs' '
+ (cd "$HTTPD_GIT_PATH"/test_repo.git &&
+ rm packed-refs &&
+ git update-ref refs/heads/master $ORIG_HEAD &&
+ git --bare update-server-info) &&
+ git push &&
+ (cd "$HTTPD_GIT_PATH"/test_repo.git &&
+ test $HEAD = $(git rev-parse --verify HEAD))
+'
+
+test_expect_success 'http-push fetches unpacked objects' '
+ cp -R "$HTTPD_GIT_PATH"/test_repo.git \
+ "$HTTPD_GIT_PATH"/test_repo_unpacked.git &&
+
+ git clone $HTTPD_GIT_URL/test_repo_unpacked.git \
+ "$ROOT_PATH"/fetch_unpacked &&
+
+ # By reset, we force git to retrieve the object
+ (cd "$ROOT_PATH"/fetch_unpacked &&
+ git reset --hard HEAD^ &&
+ git remote rm origin &&
+ git reflog expire --expire=0 --all &&
+ git prune &&
+ git push -f -v $HTTPD_GIT_URL/test_repo_unpacked.git master)
+'
+
+test_expect_success 'http-push fetches packed objects' '
+ cp -R "$HTTPD_GIT_PATH"/test_repo.git \
+ "$HTTPD_GIT_PATH"/test_repo_packed.git &&
+
+ git clone $HTTPD_GIT_URL/test_repo_packed.git \
+ "$ROOT_PATH"/test_repo_clone_packed &&
+
+ (cd "$HTTPD_GIT_PATH"/test_repo_packed.git &&
+ git --bare repack &&
+ git --bare prune-packed) &&
+
+ # By reset, we force git to retrieve the packed object
+ (cd "$ROOT_PATH"/test_repo_clone_packed &&
+ git reset --hard HEAD^ &&
+ git remote rm origin &&
+ git reflog expire --expire=0 --all &&
+ git prune &&
+ git push -f -v $HTTPD_GIT_URL/test_repo_packed.git master)
+'
+
+test_expect_success 'create and delete remote branch' '
+ cd "$ROOT_PATH"/test_repo_clone &&
+ git checkout -b dev &&
+ : >path3 &&
+ git add path3 &&
+ test_tick &&
+ git commit -m dev &&
+ git push origin dev &&
+ git fetch &&
+ git push origin :dev &&
+ git fetch &&
+ test_must_fail git show-ref --verify refs/remotes/origin/dev
+'
+
+test -n "$LIB_HTTPD_GIT" ||
+test_expect_success 'MKCOL sends directory names with trailing slashes' '
+
+ ! grep "\"MKCOL.*[^/] HTTP/[^ ]*\"" < "$HTTPD_ROOT_PATH"/access.log
+
+'
+
+x1="[0-9a-f]"
+x2="$x1$x1"
+x5="$x1$x1$x1$x1$x1"
+x38="$x5$x5$x5$x5$x5$x5$x5$x1$x1$x1"
+x40="$x38$x2"
+
+test -n "$LIB_HTTPD_GIT" ||
+test_expect_success 'PUT and MOVE sends object to URLs with SHA-1 hash suffix' '
+ sed -e "s/PUT /OP /" -e "s/MOVE /OP /" "$HTTPD_ROOT_PATH"/access.log |
+ grep -e "\"OP .*/objects/$x2/${x38}_$x40 HTTP/[.0-9]*\" 20[0-9] "
+
+'
+
+stop_httpd
+
+test_done
--
1.6.5.1.208.gd7b37
^ permalink raw reply related
* [PATCH] commit: More generous accepting of RFC-2822 footer lines.
From: David Brown @ 2009-10-28 17:13 UTC (permalink / raw)
To: git
In-Reply-To: <20091027234520.GA11433@quaoar.codeaurora.org>
From: David Brown <davidb@quicinc.com>
'git commit -s' will insert a blank line before the Signed-off-by
line at the end of the message, unless this last line is a
Signed-off-by line itself. Common use has other trailing lines
at the ends of commit text, in the style of RFC2822 headers.
Be more generous in considering lines to be part of this footer.
If the last paragraph of the commit message reasonably resembles
RFC-2822 formatted lines, don't insert that blank line.
The new Signed-off-by line is still only suppressed when the
author's existing Signed-off-by is the last line of the message.
Signed-off-by: David Brown <davidb@quicinc.com>
---
builtin-commit.c | 43 ++++++++++++++++++++++++++++++++++++++++++-
t/t7501-commit.sh | 41 +++++++++++++++++++++++++++++++++++++++++
2 files changed, 83 insertions(+), 1 deletions(-)
diff --git a/builtin-commit.c b/builtin-commit.c
index 200ffda..c395cbf 100644
--- a/builtin-commit.c
+++ b/builtin-commit.c
@@ -414,6 +414,47 @@ static void determine_author_info(void)
author_date = date;
}
+static int ends_rfc2822_footer(struct strbuf *sb)
+{
+ int ch;
+ int hit = 0;
+ int i, j, k;
+ int len = sb->len;
+ int first = 1;
+ const char *buf = sb->buf;
+
+ for (i = len - 1; i > 0; i--) {
+ if (hit && buf[i] == '\n')
+ break;
+ hit = (buf[i] == '\n');
+ }
+
+ while (i < len - 1 && buf[i] == '\n')
+ i++;
+
+ for (; i < len; i = k) {
+ for (k = i; k < len && buf[k] != '\n'; k++)
+ ; /* do nothing */
+ k++;
+
+ if ((buf[k] == ' ' || buf[k] == '\t') && !first)
+ continue;
+
+ first = 0;
+
+ for (j = 0; i + j < len; j++) {
+ ch = buf[i + j];
+ if (ch == ':')
+ break;
+ if (isalnum(ch) ||
+ (ch == '-'))
+ continue;
+ return 0;
+ }
+ }
+ return 1;
+}
+
static int prepare_to_commit(const char *index_file, const char *prefix,
struct wt_status *s)
{
@@ -489,7 +530,7 @@ static int prepare_to_commit(const char *index_file, const char *prefix,
for (i = sb.len - 1; i > 0 && sb.buf[i - 1] != '\n'; i--)
; /* do nothing */
if (prefixcmp(sb.buf + i, sob.buf)) {
- if (prefixcmp(sb.buf + i, sign_off_header))
+ if (!ends_rfc2822_footer(&sb))
strbuf_addch(&sb, '\n');
strbuf_addbuf(&sb, &sob);
}
diff --git a/t/t7501-commit.sh b/t/t7501-commit.sh
index e2ef532..d2de576 100755
--- a/t/t7501-commit.sh
+++ b/t/t7501-commit.sh
@@ -247,6 +247,47 @@ $existing" &&
'
+test_expect_success 'signoff gap' '
+
+ echo 3 >positive &&
+ git add positive &&
+ alt="Alt-RFC-822-Header: Value" &&
+ git commit -s -m "welcome
+
+$alt" &&
+ git cat-file commit HEAD | sed -e "1,/^\$/d" > actual &&
+ (
+ echo welcome
+ echo
+ echo $alt
+ git var GIT_COMMITTER_IDENT |
+ sed -e "s/>.*/>/" -e "s/^/Signed-off-by: /"
+ ) >expected &&
+ test_cmp expected actual
+'
+
+test_expect_success 'signoff gap 2' '
+
+ echo 4 >positive &&
+ git add positive &&
+ alt="fixed: 34" &&
+ git commit -s -m "welcome
+
+We have now
+$alt" &&
+ git cat-file commit HEAD | sed -e "1,/^\$/d" > actual &&
+ (
+ echo welcome
+ echo
+ echo We have now
+ echo $alt
+ echo
+ git var GIT_COMMITTER_IDENT |
+ sed -e "s/>.*/>/" -e "s/^/Signed-off-by: /"
+ ) >expected &&
+ test_cmp expected actual
+'
+
test_expect_success 'multiple -m' '
>negative &&
--
1.6.5.1
^ permalink raw reply related
* Re: From 200 to 404 to 407.
From: Avery Pennarun @ 2009-10-28 16:48 UTC (permalink / raw)
To: Peter Odéus; +Cc: git
In-Reply-To: <loom.20091028T170227-957@post.gmane.org>
On Wed, Oct 28, 2009 at 12:10 PM, Peter Odéus <peter.odeus@gmail.com> wrote:
> Anyway. Behind these corporate walls, the proxy is a reality to deal with, so
> hopefully someone else can bring us closer to a solutiuon.
I was just looking at the source and it seems all the curl-related
stuff is isolated in git/http.c, and is pretty easy to understand.
Since I have no way to reproduce your problem, I won't attempt to look
into it myself. But if you look for "proxy" (and especially
CURLOPT_PROXY) in that file, you might find something.
Specifically, I would suggest resetting the CURLOPT_PROXY setting
before each URL request (eg. in new_http_object_request).
Hope this helps.
Avery
^ permalink raw reply
* Re: From 200 to 404 to 407.
From: Avery Pennarun @ 2009-10-28 16:35 UTC (permalink / raw)
To: Peter Odéus; +Cc: git
In-Reply-To: <loom.20091028T170227-957@post.gmane.org>
On Wed, Oct 28, 2009 at 12:10 PM, Peter Odéus <peter.odeus@gmail.com> wrote:
> Avery Pennarun <apenwarr <at> gmail.com> writes:
> If you wouldn't have posted the base64-encoded password it would have never hit
> the gmane list ;-)
Sorry about that. The To: line indicated that the message had been
sent to the list, so I didn't realize that your copy was rejected. I
have no idea what made gmane reject it for you (or whether my own copy
was rejected, for that matter :)).
Avery
^ permalink raw reply
* Re: From 200 to 404 to 407.
From: Peter Odéus @ 2009-10-28 16:10 UTC (permalink / raw)
To: git
In-Reply-To: <32541b130910280850t5b4baa91p90b31b4c1c467e94@mail.gmail.com>
Avery Pennarun <apenwarr <at> gmail.com> writes:
>
> On Wed, Oct 28, 2009 at 4:38 AM, Peter Odéus <peter.odeus <at> gmail.com>
wrote:
> > * Re-using existing connection! (#0) with host proxyserver.acme.com
> > * Connected to proxyserver.acme.com (192.71.145.9) port 8080
> > > GET
>
http://gitrepo.outside.com/git/gitrepo.git/objects/6b/132a9e81161e58812902d7f735
a38bf5ee1583 HTTP/1.1
> > Proxy-Authorization: Basic cmQva3F3Zzc2MjptYW1tYW1pYQ==
> > User-Agent: git/1.6.5.2
> > Host: gitrepo.outside.com
> > Accept: */*
> >
> > * The requested URL returned error: 404
>
> So this git object didn't exist, apparently. Can you confirm that the
> object shouldn't be there? (on the server: git cat-file -p
> 6b132a9e81161e58812902d7f735a38bf5ee1583) Does git-fsck report
> anything weird on the server repository?
>
> > * Closing connection #0
> > * Couldn't find host gitrepo.outside.com in the .netrc file, using defaults
> > * About to connect() to proxyserver.acme.com port 8080
> > * Trying 192.71.145.9... * connected
> > * Connected to proxyserver.acme.com (192.71.145.9) port 8080
> > > GET http://gitrepo.outside.com/git/gitrepo.git/objects/info/http-
alternates HTTP/1.1
> > User-Agent: git/1.6.5.2
> > Host: gitrepo.outside.com
> > Accept: */*
> > Pragma: no-cache
> >
> > < HTTP/1.1 407 Proxy Authentication Required ( The ISA Server requires
> > authorization to fulfill the request. Access to the Web Proxy service
> > is denied. )
>
> This error seems to happen because the Proxy-Authorization line was
> not included in this request like it was included in prior ones.
> Probably the authorization key was forgotten when the first connection
> closed. If there hadn't been a 404, the connection wouldn't have
> closed and this wouldn't have happened, which is presumably why you
> haven't seen this problem before.
>
> This is where my expertise ends, since I've never messed with either
> libcurl or git's usage of it. I couldn't tell you if this is a
> libcurl bug or a git bug. (Proxies are relatively rare nowadays, so
> this code path is likely to be rarely tested.)
>
> Hopefully someone else on the list can assist.
>
> ** WARNING: the username/password sent in the Proxy-Authorization line
> is not encrypted and you've posted a trace of it to a public mailing
> list. You need to change your password immediately. **
>
> Good luck,
>
> Avery
>
If you wouldn't have posted the base64-encoded password it would have never hit
the gmane list ;-)
Don't worry about it, because I tried to submit the console output myself all
day. But to no avail.
Is it enough to replace greater-than-signs to something else, btw?
Anyway. Behind these corporate walls, the proxy is a reality to deal with, so
hopefully someone else can bring us closer to a solutiuon.
Thanks for your input.
:D
/Peter
^ permalink raw reply
* Re: git svn branch tracking + ignore paths
From: Avery Pennarun @ 2009-10-28 16:00 UTC (permalink / raw)
To: Lachlan Deck; +Cc: git list
In-Reply-To: <19979334-07EB-48CA-8E62-4ECC5E1FA51C@gmail.com>
On Wed, Oct 28, 2009 at 1:59 AM, Lachlan Deck <lachlan.deck@gmail.com> wrote:
> On 28/10/2009, at 4:20 PM, Avery Pennarun wrote:
>> So which are the files you don't want to import from trunk? It
>> doesn't sound like there are any... so it's getting simpler already.
>
> There are. I've currently (as a workaround) done the following within the
> main branch:
> add the following to .git/info/exclude
> .settings
> target
> .classpath
> .project
>
> The last two of these has no effect of course because .project and
> .classpath files already exist -- and thus are marked as modified. So I'm
> currently doing a git stash && git svn rebase && git svn dcommit && git
> stash pop
>
> I'm also wanting to exclude 'lib' folders from trunk (as these are not
> needed).
The problem is that as your branch diverges from what you *actually*
want to commit, it becomes exponentially more complicated to figure
out what you *do* want to commit.
Note that if you're planning to share your git project with other
people anyway, then you have an additional problem: you're using git
svn rebase, which is almost useless for sharing with other people
(other than through svn, of course), for the same reason any git
rebase is.
One option you have is to maintain two branches:
1. (git-svn) The git-svn trunk, which contains only stuff you want upstream
2. (master) Your live branch, which contains everything from (1) plus
your local customizations.
When you want to fetch from svn, you do this:
git checkout master
git svn fetch git-svn
git merge git-svn
When you want to push to svn, you do this:
git checkout git-svn
git merge --squash --no-commit master
(now undo your local customizations)
git commit
git svn dcommit
git checkout master
git merge git-svn
Note that master never gets rebased, only merged. If you can write a
simple script for "undo your local customizations" - such as reverting
a particular commit, for example - then you can put the above in a
shell script and it should work fine most of the time.
Good luck.
Avery
^ permalink raw reply
* Re: From 200 to 404 to 407.
From: Avery Pennarun @ 2009-10-28 15:50 UTC (permalink / raw)
To: Peter Odéus; +Cc: git
In-Reply-To: <82fd2c5d0910280138r52baff98p3f4ff65e968b0d37@mail.gmail.com>
On Wed, Oct 28, 2009 at 4:38 AM, Peter Odéus <peter.odeus@gmail.com> wrote:
> * Re-using existing connection! (#0) with host proxyserver.acme.com
> * Connected to proxyserver.acme.com (192.71.145.9) port 8080
> > GET http://gitrepo.outside.com/git/gitrepo.git/objects/6b/132a9e81161e58812902d7f735a38bf5ee1583 HTTP/1.1
> Proxy-Authorization: Basic cmQva3F3Zzc2MjptYW1tYW1pYQ==
> User-Agent: git/1.6.5.2
> Host: gitrepo.outside.com
> Accept: */*
>
> * The requested URL returned error: 404
So this git object didn't exist, apparently. Can you confirm that the
object shouldn't be there? (on the server: git cat-file -p
6b132a9e81161e58812902d7f735a38bf5ee1583) Does git-fsck report
anything weird on the server repository?
> * Closing connection #0
> * Couldn't find host gitrepo.outside.com in the .netrc file, using defaults
> * About to connect() to proxyserver.acme.com port 8080
> * Trying 192.71.145.9... * connected
> * Connected to proxyserver.acme.com (192.71.145.9) port 8080
> > GET http://gitrepo.outside.com/git/gitrepo.git/objects/info/http-alternates HTTP/1.1
> User-Agent: git/1.6.5.2
> Host: gitrepo.outside.com
> Accept: */*
> Pragma: no-cache
>
> < HTTP/1.1 407 Proxy Authentication Required ( The ISA Server requires
> authorization to fulfill the request. Access to the Web Proxy service
> is denied. )
This error seems to happen because the Proxy-Authorization line was
not included in this request like it was included in prior ones.
Probably the authorization key was forgotten when the first connection
closed. If there hadn't been a 404, the connection wouldn't have
closed and this wouldn't have happened, which is presumably why you
haven't seen this problem before.
This is where my expertise ends, since I've never messed with either
libcurl or git's usage of it. I couldn't tell you if this is a
libcurl bug or a git bug. (Proxies are relatively rare nowadays, so
this code path is likely to be rarely tested.)
Hopefully someone else on the list can assist.
** WARNING: the username/password sent in the Proxy-Authorization line
is not encrypted and you've posted a trace of it to a public mailing
list. You need to change your password immediately. **
Good luck,
Avery
^ permalink raw reply
* Re: merge confusion
From: Alex Riesen @ 2009-10-28 15:43 UTC (permalink / raw)
To: Tim Mazid; +Cc: git
In-Reply-To: <26093419.post@talk.nabble.com>
On Wed, Oct 28, 2009 at 13:01, Tim Mazid <timmazid@hotmail.com> wrote:
> You can just do a 'git branch branch-to-merge COMMIT' then 'git merge
> branch-to-merge' from your feature branch. Alternatively, you could just do
> a straight 'git merge COMMIT' from your feature branch. Though I'm not sure
> of the consequences of merging a commit instead of a branch.
The only consequence is that the merge commit message (if there will be any,
fast-forward merges don't merge anything) will mention the SHA1 instead of
branch name. You can provide your own merge commit message, of course
(while merging and afterwards).
^ permalink raw reply
* Re: [PATCH] mergetool--lib: add p4merge as a pre-configured mergetool option
From: Scott Chacon @ 2009-10-28 15:37 UTC (permalink / raw)
To: David Aguilar; +Cc: Charles Bailey, git list, Junio C Hamano
In-Reply-To: <20091028090022.GA90780@gmail.com>
Hey,
On Wed, Oct 28, 2009 at 2:00 AM, David Aguilar <davvid@gmail.com> wrote:
>> I'm just wondering, does this work well with unixes and Mac OS X? I
>> think it's recommended install practice to symlink p4v as p4merge on
>> *nix, but Mac OS X needs some sort of 'launchp4merge' to be called
>> IIRC, or is this something that users can just configure with
>> mergetool.p4diff.path?
>
> I just tested this on Mac OS X with the latest version of
> p4merge. It worked great.
>
> $ git config difftool.p4merge.path \
> /Applications/p4merge.app/Contents/MacOS/p4merge
>
> $ git difftool -t p4merge HEAD^
>
This is how I have it setup as well and both diff and merge work for
me. I had to do a weird thing with passing it $LOCAL twice if there
was no merge base since otherwise it does a diff tool instead of a
merge tool - the difference is based on the number of arguments, but
it seems to work pretty well. I can try it on Linux a bit later, but
I'm not sure why launchp4merge would be needed instead of setting the
path like this on a Mac - if there is no serious objection, I can
resend this with my Signed-Off-By (sorry, I forgot).
Thanks,
Scott
^ permalink raw reply
* Re: From 200 to 404 to 407.
From: Peter Odéus @ 2009-10-28 15:35 UTC (permalink / raw)
To: git
In-Reply-To: <loom.20091028T160202-594@post.gmane.org>
Peter <peter.odeus <at> gmail.com> writes:
>
>
> Don't have root access at work == no wireshark.
>
>
I have tried to attach rich console output (thanks to env variable
GIT_CURL_VERBOSE=1) into a gmane-follow-up-message.
No dice.
Are there restrictions on what characters are permitted?
^ permalink raw reply
* Re: how to split a hunk
From: bill lam @ 2009-10-28 15:26 UTC (permalink / raw)
To: Geert Bosch; +Cc: git
In-Reply-To: <21963906-785A-4D98-8AD8-A89ED914920C@adacore.com>
On Tue, 27 Oct 2009, Geert Bosch wrote:
> I like to use "git gui" for this. This allows you to pick individual
> lines to commit. I really like the "git gui" interface for staging/unstaging
> changes and making a series of commits.
Thank you suggestion. However I did not use git-gui/gitk or have tcl
installed.
--
regards,
====================================================
GPG key 1024D/4434BAB3 2008-08-24
gpg --keyserver subkeys.pgp.net --recv-keys 4434BAB3
^ permalink raw reply
* packaging vs default pager
From: Ben Walton @ 2009-10-28 15:21 UTC (permalink / raw)
To: GIT List
[-- Attachment #1: Type: text/plain, Size: 999 bytes --]
Hi All,
I'd like to see what people think about providing a configure/Makefile
knob for overriding the default pager at build time. Currently,
things use 'less' as the fallback and rely on the path to find
it.
On (old) solaris systems, /usr/bin/less (typically the first less
found) doesn't understand the default arguments (FXRS), which forces
users to alter their environment (PATH, GIT_PAGER, LESS, etc) or have
a local or global gitconfig before paging works as expected.
Would it be completely out of line to provide a knob so that the
fallback $pager could be set to something more specific/appropriate
during the build? [I'll do the work but not if it's an undesirable
addition.]
Alternately, are packagers recommended to simply ship a global
gitconfig that sets core.pager?
Thanks
-Ben
--
Ben Walton
Systems Programmer - CHASS
University of Toronto
C:416.407.5610 | W:416.978.4302
GPG Key Id: 8E89F6D2; Key Server: pgp.mit.edu
Contact me to arrange for a CAcert assurance meeting.
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: how to split a hunk
From: bill lam @ 2009-10-28 15:16 UTC (permalink / raw)
To: Thomas Rast; +Cc: git
In-Reply-To: <200910281406.12923.trast@student.ethz.ch>
On Wed, 28 Oct 2009, Thomas Rast wrote:
> There's also the 'git add -p' [e]dit feature, which pops up the patch
> in an editor. There are instructions in that file, but in this case,
> you can simply remove one of the additions.
Thank you for pointing out the [e], incidentally after trying it, I
also noticed and tried the add -e which belongs to a similar format.
--
regards,
====================================================
GPG key 1024D/4434BAB3 2008-08-24
gpg --keyserver subkeys.pgp.net --recv-keys 4434BAB3
^ permalink raw reply
* Re: From 200 to 404 to 407.
From: Peter @ 2009-10-28 15:02 UTC (permalink / raw)
To: git
In-Reply-To: <32541b130910270953w6bd35ddctd471e682830b8f62@mail.gmail.com>
Don't have root access at work == no wireshark.
^ permalink raw reply
* Re: sp/smart-http topic
From: Shawn O. Pearce @ 2009-10-28 14:47 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7veiovly35.fsf@alter.siamese.dyndns.org>
Junio C Hamano <gitster@pobox.com> wrote:
>
> * sp/smart-http (2009-10-14) 17 commits
> - Smart fetch over HTTP: client side
...
> What's the doneness of this series?
Not done yet. I want to respin once more before it hits next.
I've picked up a number of test related changes from Clemens
Buchacher and Tay Ray Chuan, plus some suggestions from the latter
were fixed up in the WebDAV code.
John "warthog9" Hawley and I were spending some time yesterday to
try to figure out why smart HTTP serving off kernel.org was giving
me only 300 KiB/sec during clone, but git-daemon was giving me 12
MiB/sec for the same server and repository.
Peff noticed the TCP windows for smart HTTP were ~16 KiB in size,
but with git-daemon were ~200 KiB on size. John and I are pretty
sure this is the throughput problem, but we haven't found why the
window is so much smaller under smart HTTP.
We also need proper tests for smart HTTP. I haven't had time to
write tests yet, and the ones that were proposed for t5540-http-push
aren't suitable because you have to run the test suite twice in
order to test both WebDAV and smart HTTP push for the same build.
--
Shawn.
^ permalink raw reply
* Re: possible usability issue in rebase -i?
From: Erik Faye-Lund @ 2009-10-28 14:41 UTC (permalink / raw)
To: Baz; +Cc: Git Mailing List
In-Reply-To: <2faad3050910280734l7297c30erfb0a47b12b0bd07d@mail.gmail.com>
On Wed, Oct 28, 2009 at 3:34 PM, Baz <brian.ewins@gmail.com> wrote:
> 2009/10/28 Erik Faye-Lund <kusmabite@googlemail.com>:
>> I'm not sure I follow - aren't dashless options, uhm, dashless? Do you
>> mean to use the long-form instead of the short-form? I'll assume
>> that's what you mean for now, since you changed "-i" to "--interactive
>> | -i".
>
> No, I just meant 'git rebase' not 'git-rebase'. Sorry, I changed a
> couple of things at once.
Ah, didn't notice that one. I completely agree with you on this.
> tend to emit one-liners. As for calling out 'interactive', at the
> other extreme its not clear to me why we mention '-i' separately from
> '[options]' at all. rebase is already pretty inconsistent here, giving
> short or long usage messages depending on whether you passed '-i'. But
> I'll take comments on this when I submit the patch, I've no strong
> feelings on it.
It's a simple reason why the output is different - this is the usage
for "git rebase -i" (hence it is in git-rebase--interactive.sh). I
guess this distinction would be slightly clearer if we removed the
brackets from the usage like this:
-git-rebase [-i] [whatever]
+git-rebase -i [whatever]
--
Erik "kusma" Faye-Lund
^ permalink raw reply
* Re: possible usability issue in rebase -i?
From: Baz @ 2009-10-28 14:34 UTC (permalink / raw)
To: kusmabite; +Cc: Git Mailing List
In-Reply-To: <40aa078e0910280520t497f1289sf374a3a501856a23@mail.gmail.com>
2009/10/28 Erik Faye-Lund <kusmabite@googlemail.com>:
> On Tue, Oct 27, 2009 at 10:05 PM, Baz <brian.ewins@gmail.com> wrote:
>> I'm fine with this way of fixing it, but I'd make a few more changes...
>
> Feel free to make a patch-series that addresses more issues - I'm not going to.
>
Yep, I wrote one but had to leave the house before sending it. Later today.
> We make patches of one change at the time in Git. Other (related)
> usability issues becomes separate patches, preferably grouped together
> in a patch-series. This change would be one patch in such a series.
>
>>> OPTIONS_SPEC="\
>>> git-rebase [-i] [options] [--] <upstream> [<branch>]
>>
>> Use the dashless form and be more consistent with the help - and
>> mention '--root' here, it appears in the
>> help below:
>>
>> -git-rebase [-i] [options] [--] <upstream> [<branch>]
>> +git rebase [--interactive | -i] [options] [--onto <newbase>] [--]
>> <upstream> [<branch>]
>> +git rebase [--interactive | -i] [options] --onto <newbase> --root
>> [--] [<branch>]
>>
>
> I'm not sure I follow - aren't dashless options, uhm, dashless? Do you
> mean to use the long-form instead of the short-form? I'll assume
> that's what you mean for now, since you changed "-i" to "--interactive
> | -i".
No, I just meant 'git rebase' not 'git-rebase'. Sorry, I changed a
couple of things at once.
>
> If so, I'm not 100% convinced it's a clear win: some grep'ing
> indicates that both the short and long form are both widely used, with
> short-option bein a slight favor:
> $ git grep " \[--" | grep -v " \[--\]" | wc -l
> 228
> $ git grep " \[-[^-]" | wc -l
> 243
>
> Also, the usage isn't the only documentation. I think it makes sense
> to try to keep the usage short and to the point, there's a list
> describing each option (showing the full-name) further down in the
> usage-message. And if that's not enough, there's the "git
> help"-command.
>
> If I've misunderstood you and you only want the usage-string to match
> that of the manpage, perhaps that might be a good idea. I dunno.
In the patch I've followed other uses of OPTIONS_SPEC; they're quite
verbose, covering all options, while scripts using USAGE/LONG_USAGE
tend to emit one-liners. As for calling out 'interactive', at the
other extreme its not clear to me why we mention '-i' separately from
'[options]' at all. rebase is already pretty inconsistent here, giving
short or long usage messages depending on whether you passed '-i'. But
I'll take comments on this when I submit the patch, I've no strong
feelings on it.
>
>>
>>> -git-rebase [-i] (--continue | --abort | --skip)
>>> +git-rebase [-i] [-m] (--continue | --abort | --skip)
>>
>> Again, dashless. And I'd not mention the useless -i here, the man page
>> doesn't either:
>>
>> -git-rebase [-i] (--continue | --abort | --skip)
>> +git rebase (--continue | --abort | --skip)
>>
>
> It was already there, so I didn't consider it, but I guess it makes
> sense. Besides, I aimed at not loosing any information while making it
> a bit clearer.
>
>> These two items are misplaced in the help (I think). They're not like
>> abort, continue, skip, but then, the man page doesn't group those
>> separately either.
>>
>> +no-verify override pre-rebase hook from stopping the operation
>> +root rebase all reachable commmits up to the root(s)
>>
>
> Agree.
>
>>> Actions:
>>> continue continue rebasing process
>>> abort abort rebasing process and restore original branch
>>
>> As above, remove the next two lines after your patch:
>>
>> -no-verify override pre-rebase hook from stopping the operation
>> -root rebase all reachable commmits up to the root(s)
>
> I don't follow this. Are you repeating yourself now? :)
Yes :) ... was just finishing off moving those two lines.
Cheers,
Baz
>
> --
> Erik "kusma" Faye-Lund
>
^ permalink raw reply
* Re: [PATCH] bash completion: difftool accepts the same options as diff
From: Shawn O. Pearce @ 2009-10-28 14:32 UTC (permalink / raw)
To: Markus Heidelberg; +Cc: Junio C Hamano, git, David Aguilar
In-Reply-To: <1256723138-1480-1-git-send-email-markus.heidelberg@web.de>
Markus Heidelberg <markus.heidelberg@web.de> wrote:
> So complete refs, files after the doubledash and some diff options that
> make sense for difftool.
>
> Signed-off-by: Markus Heidelberg <markus.heidelberg@web.de>
Acked-by: Shawn O. Pearce <spearce@spearce.org>
> contrib/completion/git-completion.bash | 10 ++++++++--
> 1 files changed, 8 insertions(+), 2 deletions(-)
--
Shawn.
^ permalink raw reply
* Re: [PATCH] commit: More generous accepting of RFC-2822 footer lines.
From: David Brown @ 2009-10-28 14:23 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Shawn O. Pearce, David Brown, git@vger.kernel.org
In-Reply-To: <7vk4yguh00.fsf@alter.siamese.dyndns.org>
On Wed, Oct 28, 2009 at 12:14:55AM -0700, Junio C Hamano wrote:
> When deciding to omit adding a new S-o-b, we deliberately check only the
> last S-o-b to see if it matches what we are trying to add. This is so
> that a message from you, that has my patch that was reviewed and touched
> up by you with your sign-off, i.e.
This is good to know. I'll leave the existing last-SoB test in
place then, and just use the sophisticated check for a block of
RFC2822 footers to determine if there should be a blank line.
Jeff also pointed out that I should probably also allow lines
starting with whitespace to be considered header lines.
David
^ permalink raw reply
* Re: [PATCH] imap-send.c: fix pointer to be const
From: Michael J Gruber @ 2009-10-28 13:33 UTC (permalink / raw)
To: Vietor Liu; +Cc: Junio C Hamano, git
In-Reply-To: <1256713526.3333.0.camel@localhost.localdomain>
Vietor Liu venit, vidit, dixit 28.10.2009 08:05:
> On Tue, 2009-10-27 at 23:26 -0700, Junio C Hamano wrote:
>> Vietor Liu <vietor@vxwo.org> writes:
>>
>>> Fixes some compiler warnings:
>>> imap-send.c: In function ‘ssl_socket_connect’:
>>> warning: assignment discards qualifiers from pointer target type
>>>
>>> Signed-off-by: Vietor Liu <vietor@vxwo.org>
>>
>> I do not quite understand. This variable gets assigned the return values
>> from TLSv1_method() or SSLv23_method(), but the copy of ssl.h I have
>> declares them as:
>>
>> SSL_METHOD *SSLv23_method(void); /* SSLv3 but can rollback to v2 */
>> SSL_METHOD *TLSv1_method(void); /* TLSv1.0 */
>
> 1. openssl-devel-1.0.0-0.10
>
> const SSL_METHOD *SSLv23_method(void); /* SSLv3 but can rollback to v2
> */
> const SSL_METHOD *TLSv1_method(void); /* TLSv1.0 */
>
>
> 2. http://www.openssl.org/docs/ssl/ssl.html
>
> const SSL_METHOD *SSLv2_method(void);
>
> Constructor for the SSLv2 SSL_METHOD structure for combined
> client and server.
> const SSL_METHOD *TLSv1_method(void);
>
> Constructor for the TLSv1 SSL_METHOD structure for combined
> client and server.
>
> 3. it maybe fixes warnings for other version.
No const here with openssl 0.9.8k. I think major distros will switch to
1.0.0 with their next major release (e.g. Fedora 12 will have it by the
end of this year).
Since this is only about warnings, maybe git 1.7.0 is the right time
frame to adjust this to the upcoming standard?
Michael
^ permalink raw reply
* Re: how to split a hunk
From: Thomas Rast @ 2009-10-28 13:06 UTC (permalink / raw)
To: bill lam; +Cc: git
In-Reply-To: <20091028022105.GE3938@debian.b2j>
bill lam wrote:
> There are occasions where diff of a file is
>
> - aaaa
> + bbbb
> + cccc
>
> I want to add lines bbbb and cccc as separated commits, but git-add -p
> seem cannot further split this hunk. Do I have no choice but to edit
> it by hand and commit the bbbb and then edit the file to add back the
> cccc?
There's also the 'git add -p' [e]dit feature, which pops up the patch
in an editor. There are instructions in that file, but in this case,
you can simply remove one of the additions.
--
Thomas Rast
trast@{inf,student}.ethz.ch
^ 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