Re: PROPFIND 405 with git-http-backend and Smart HTTP
You need to allow the directory to be read? directory Path/to/your/repositories Allow from all /directory -- View this message in context: http://git.661346.n2.nabble.com/PROPFIND-405-with-git-http-backend-and-Smart-HTTP-tp7564017p7616843.html Sent from the git mailing list archive at Nabble.com. -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 1/2] fetch: convert argv_gc_auto to struct argv_array
Signed-off-by: Nguyễn Thái Ngọc Duy pclo...@gmail.com
---
builtin/fetch.c | 7 +++
1 file changed, 3 insertions(+), 4 deletions(-)
diff --git a/builtin/fetch.c b/builtin/fetch.c
index e8d0cca..9394194 100644
--- a/builtin/fetch.c
+++ b/builtin/fetch.c
@@ -1110,9 +1110,7 @@ int cmd_fetch(int argc, const char **argv, const char
*prefix)
struct string_list list = STRING_LIST_INIT_NODUP;
struct remote *remote;
int result = 0;
- static const char *argv_gc_auto[] = {
- gc, --auto, NULL,
- };
+ struct argv_array argv_gc_auto = ARGV_ARRAY_INIT;
packet_trace_identity(fetch);
@@ -1198,7 +1196,8 @@ int cmd_fetch(int argc, const char **argv, const char
*prefix)
list.strdup_strings = 1;
string_list_clear(list, 0);
- run_command_v_opt(argv_gc_auto, RUN_GIT_CMD);
+ argv_array_pushl(argv_gc_auto, gc, --auto, NULL);
+ run_command_v_opt(argv_gc_auto.argv, RUN_GIT_CMD);
return result;
}
--
2.1.0.rc0.78.gc0d8480
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 2/2] fetch: silence git-gc if --quiet is given
Noticed-by: Matthew Flaschen mflasc...@wikimedia.org Signed-off-by: Nguyễn Thái Ngọc Duy pclo...@gmail.com --- builtin/fetch.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/builtin/fetch.c b/builtin/fetch.c index 9394194..4ff4080 100644 --- a/builtin/fetch.c +++ b/builtin/fetch.c @@ -1197,6 +1197,8 @@ int cmd_fetch(int argc, const char **argv, const char *prefix) string_list_clear(list, 0); argv_array_pushl(argv_gc_auto, gc, --auto, NULL); + if (verbosity 0) + argv_array_push(argv_gc_auto,--quiet); run_command_v_opt(argv_gc_auto.argv, RUN_GIT_CMD); return result; -- 2.1.0.rc0.78.gc0d8480 -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Git on Mac OS X 10.4.10
I'm new to this list, so: Hello everybody! My backup servers run Mac OS X 10.4.10. Yes, these are old, but very reliable and easily up to the task. And Mac OS X 10.4 is the latest OS supported there (PowerPC G3). Recently I tried to upgrade to v2.0.4 (from 1.7.11.4). Issue 1: I get many of these warnings: LINK [many cases] /usr/bin/ld: warning multiple definitions of symbol _regcomp libgit.a(regex.o) definition of _regcomp in section (__TEXT,__text) /usr/lib/gcc/powerpc-apple-darwin8/4.0.1/../../../libSystem.dylib(regcomp.So) definition of _regcomp /usr/bin/ld: warning multiple definitions of symbol _regexec libgit.a(regex.o) definition of _regexec in section (__TEXT,__text) /usr/lib/gcc/powerpc-apple-darwin8/4.0.1/../../../libSystem.dylib(regexec.So) definition of _regexec /usr/bin/ld: warning multiple definitions of symbol _regfree libgit.a(regex.o) definition of _regfree in section (__TEXT,__text) /usr/lib/gcc/powerpc-apple-darwin8/4.0.1/../../../libSystem.dylib(regfree.So) definition of _regfree Is this expected? Issue 2: I need this simple patch ... --- compat/apple-common-crypto.h.org2014-07-30 23:19:53.0 +0200 +++ compat/apple-common-crypto.h2014-08-14 12:57:37.0 +0200 @@ -2,7 +2,7 @@ #define OPENSSL_NO_MD5 #define HEADER_HMAC_H #define HEADER_SHA_H -#include CommonCrypto/CommonHMAC.h +//#include CommonCrypto/CommonHMAC.h #define HMAC_CTX CCHmacContext #define HMAC_Init(hmac, key, len, algo) CCHmacInit(hmac, algo, key, len) #define HMAC_Update CCHmacUpdate ... and this command sequence ... make all touch imap-send.o touch git-imap-send make all ... to get it compiling. All, except git-imap-send, obviously, which is no loss for my purposes. I tried many releases, the patch requirement started with about v1.9.1, the git-imap-send failure somewhere between 1.8.1.6 and 1.8.4.3. Trying to be a good Open Source citizen, how would I proceed? Thanks, Markus P.S.1: error without the patch is: In file included from git-compat-util.h:330, from cache.h:4, from advice.c:1: compat/apple-common-crypto.h:5:37: error: CommonCrypto/CommonHMAC.h: No such file or directory P.S.2: error without faking git-imap-send is: CC imap-send.o imap-send.c: In function ‘cram’: imap-send.c:881: error: ‘CCHmacContext’ undeclared (first use in this function) imap-send.c:881: error: (Each undeclared identifier is reported only once imap-send.c:881: error: for each function it appears in.) imap-send.c:881: error: parse error before ‘hmac’ imap-send.c:896: error: ‘hmac’ undeclared (first use in this function) imap-send.c:896: error: ‘kCCHmacAlgMD5’ undeclared (first use in this function) make: *** [imap-send.o] Error 1 -- - - - - - - - - - - - - - - - - - - - Dipl. Ing. (FH) Markus Hitter http://www.jump-ing.de/ -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Git on Mac OS X 10.4.10
On 08/14/2014 02:13 PM, Markus Hitter wrote: I'm new to this list, so: Hello everybody! My backup servers run Mac OS X 10.4.10. Yes, these are old, but very reliable and easily up to the task. And Mac OS X 10.4 is the latest OS supported there (PowerPC G3). Recently I tried to upgrade to v2.0.4 (from 1.7.11.4). Issue 1: I get many of these warnings: LINK [many cases] /usr/bin/ld: warning multiple definitions of symbol _regcomp libgit.a(regex.o) definition of _regcomp in section (__TEXT,__text) /usr/lib/gcc/powerpc-apple-darwin8/4.0.1/../../../libSystem.dylib(regcomp.So) definition of _regcomp /usr/bin/ld: warning multiple definitions of symbol _regexec libgit.a(regex.o) definition of _regexec in section (__TEXT,__text) /usr/lib/gcc/powerpc-apple-darwin8/4.0.1/../../../libSystem.dylib(regexec.So) definition of _regexec /usr/bin/ld: warning multiple definitions of symbol _regfree libgit.a(regex.o) definition of _regfree in section (__TEXT,__text) /usr/lib/gcc/powerpc-apple-darwin8/4.0.1/../../../libSystem.dylib(regfree.So) definition of _regfree Is this expected? No. Git has its own regcomp() (and the regXXX() ) in ./compat/regex/*, and for some reasons the linker picks them both from libgit.a (which is a static library) and the dynamic library in libSystem.dylib Either the linker needs to be convinced not to do that (by changing the command line to the linker, changing the order of libraries may help, I don't know) Or each regcomp in the .h and .c files is changed into git_regcomp. This change shouldn't break anything. Issue 2: I need this simple patch ... --- compat/apple-common-crypto.h.org2014-07-30 23:19:53.0 +0200 +++ compat/apple-common-crypto.h2014-08-14 12:57:37.0 +0200 @@ -2,7 +2,7 @@ #define OPENSSL_NO_MD5 #define HEADER_HMAC_H #define HEADER_SHA_H -#include CommonCrypto/CommonHMAC.h +//#include CommonCrypto/CommonHMAC.h #define HMAC_CTX CCHmacContext #define HMAC_Init(hmac, key, len, algo) CCHmacInit(hmac, algo, key, len) #define HMAC_Update CCHmacUpdate The CommonCrypto/CommonHMAC.h is in Mac OS X 10.6 .. 10.9, but not in 10.4 (I don't know about 10.5). You can try to tweak the makefiles, search for NO_APPLE_COMMON_CRYPTO, and set NO_APPLE_COMMON_CRYPTO, but only for Darwin 10.3 (or below) ... and this command sequence ... make all touch imap-send.o touch git-imap-send make all ... to get it compiling. All, except git-imap-send, obviously, which is no loss for my purposes. I tried many releases, the patch requirement started with about v1.9.1, the git-imap-send failure somewhere between 1.8.1.6 and 1.8.4.3. Trying to be a good Open Source citizen, how would I proceed? If you want to share your changes, please send a patch to this list. Thanks, Markus -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v3 1/6] wrapper.c: introduce gentle xmalloc(z) that does not die()
Nguyễn Thái Ngọc Duy pclo...@gmail.com writes:
Signed-off-by: Nguyễn Thái Ngọc Duy pclo...@gmail.com
---
I think the basic idea is sound.
git grep -e _gentle -e _gently -e _gentler hints me that the new
functions are somewhat misnamed, though.
git-compat-util.h | 2 ++
wrapper.c | 73
+++
2 files changed, 59 insertions(+), 16 deletions(-)
diff --git a/git-compat-util.h b/git-compat-util.h
index f587749..0e541e7 100644
--- a/git-compat-util.h
+++ b/git-compat-util.h
@@ -592,7 +592,9 @@ extern try_to_free_t
set_try_to_free_routine(try_to_free_t);
#endif
extern char *xstrdup(const char *str);
extern void *xmalloc(size_t size);
+extern void *xmalloc_gentle(size_t size);
extern void *xmallocz(size_t size);
+extern void *xmallocz_gentle(size_t size);
extern void *xmemdupz(const void *data, size_t len);
extern char *xstrndup(const char *str, size_t len);
extern void *xrealloc(void *ptr, size_t size);
diff --git a/wrapper.c b/wrapper.c
index bc1bfb8..ad0992a 100644
--- a/wrapper.c
+++ b/wrapper.c
@@ -9,16 +9,23 @@ static void do_nothing(size_t size)
static void (*try_to_free_routine)(size_t size) = do_nothing;
-static void memory_limit_check(size_t size)
+static int memory_limit_check(size_t size, int gentle)
{
static int limit = -1;
if (limit == -1) {
const char *env = getenv(GIT_ALLOC_LIMIT);
limit = env ? atoi(env) * 1024 : 0;
}
- if (limit size limit)
- die(attempting to allocate %PRIuMAX over limit %d,
- (intmax_t)size, limit);
+ if (limit size limit) {
+ if (gentle) {
+ error(attempting to allocate %PRIuMAX over limit %d,
+ (intmax_t)size, limit);
+ return -1;
+ } else
+ die(attempting to allocate %PRIuMAX over limit %d,
+ (intmax_t)size, limit);
+ }
+ return 0;
}
try_to_free_t set_try_to_free_routine(try_to_free_t routine)
@@ -42,11 +49,12 @@ char *xstrdup(const char *str)
return ret;
}
-void *xmalloc(size_t size)
+static void *do_xmalloc(size_t size, int gentle)
{
void *ret;
- memory_limit_check(size);
+ if (memory_limit_check(size, gentle))
+ return NULL;
ret = malloc(size);
if (!ret !size)
ret = malloc(1);
@@ -55,9 +63,16 @@ void *xmalloc(size_t size)
ret = malloc(size);
if (!ret !size)
ret = malloc(1);
- if (!ret)
- die(Out of memory, malloc failed (tried to allocate
%lu bytes),
- (unsigned long)size);
+ if (!ret) {
+ if (!gentle)
+ die(Out of memory, malloc failed (tried to
allocate %lu bytes),
+ (unsigned long)size);
+ else {
+ error(Out of memory, malloc failed (tried to
allocate %lu bytes),
+ (unsigned long)size);
+ return NULL;
+ }
+ }
}
#ifdef XMALLOC_POISON
memset(ret, 0xA5, size);
@@ -65,16 +80,42 @@ void *xmalloc(size_t size)
return ret;
}
-void *xmallocz(size_t size)
+void *xmalloc(size_t size)
+{
+ return do_xmalloc(size, 0);
+}
+
+void *xmalloc_gentle(size_t size)
+{
+ return do_xmalloc(size, 1);
+}
+
+static void *do_xmallocz(size_t size, int gentle)
{
void *ret;
- if (unsigned_add_overflows(size, 1))
- die(Data too large to fit into virtual memory space.);
- ret = xmalloc(size + 1);
- ((char*)ret)[size] = 0;
+ if (unsigned_add_overflows(size, 1)) {
+ if (gentle) {
+ error(Data too large to fit into virtual memory
space.);
+ return NULL;
+ } else
+ die(Data too large to fit into virtual memory space.);
+ }
+ ret = do_xmalloc(size + 1, gentle);
+ if (ret)
+ ((char*)ret)[size] = 0;
return ret;
}
+void *xmallocz(size_t size)
+{
+ return do_xmallocz(size, 0);
+}
+
+void *xmallocz_gentle(size_t size)
+{
+ return do_xmallocz(size, 1);
+}
+
/*
* xmemdupz() allocates (len + 1) bytes of memory, duplicates len bytes of
* data to the allocated memory, zero terminates the allocated memory,
@@ -96,7 +137,7 @@ void *xrealloc(void *ptr, size_t size)
{
void *ret;
- memory_limit_check(size);
+ memory_limit_check(size, 0);
ret = realloc(ptr, size);
if (!ret !size)
ret = realloc(ptr, 1);
@@ -115,7 +156,7 @@ void *xcalloc(size_t nmemb, size_t size)
{
void *ret;
- memory_limit_check(size * nmemb);
+
Re: [PATCH v3 3/6] unpack-objects: continue when fail to malloc due to large objects
Nguyễn Thái Ngọc Duy pclo...@gmail.com writes:
As a recovery tool, unpack-objects should go on unpacking as many
objects as it can.
Signed-off-by: Nguyễn Thái Ngọc Duy pclo...@gmail.com
---
builtin/unpack-objects.c | 42 +-
t/t1050-large.sh | 7 +++
2 files changed, 48 insertions(+), 1 deletion(-)
diff --git a/builtin/unpack-objects.c b/builtin/unpack-objects.c
index 99cde45..8b5c67e 100644
--- a/builtin/unpack-objects.c
+++ b/builtin/unpack-objects.c
@@ -88,10 +88,50 @@ static void use(int bytes)
consumed_bytes += bytes;
}
+static void inflate_and_throw_away(unsigned long size)
+{
+ git_zstream stream;
+ char buf[8192];
+
+ memset(stream, 0, sizeof(stream));
+ stream.next_out = (unsigned char *)buf;
+ stream.avail_out = sizeof(buf);
+ stream.next_in = fill(1);
+ stream.avail_in = len;
+ git_inflate_init(stream);
+
+ for (;;) {
+ int ret = git_inflate(stream, 0);
+ use(len - stream.avail_in);
+ if (stream.total_out == size ret == Z_STREAM_END)
+ break;
+ if (ret != Z_OK) {
+ error(inflate returned %d, ret);
+ if (!recover)
+ exit(1);
+ has_errors = 1;
+ break;
+ }
+ stream.next_out = (unsigned char *)buf;
+ stream.avail_out = sizeof(buf);
+ stream.next_in = fill(1);
+ stream.avail_in = len;
+ }
+ git_inflate_end(stream);
+}
This looks wrong in a few ways.
You already know that we saw an error when you get to this function,
whether you will see an out-of-sync stream in this loop or not, so
there is no reason to copy the assignment to has_errors from the
other function. You also know 'recover' is true---otherwise you
wouldn't be here.
But more importantly, the basic structure of this loop is the same
as the loop we already have in the only caller of this new function,
not just the regular zlib produced this much that is not yet the
expected size, go on reading more and we are at the end of the
stream with Z_STREAM_END, and we are done, but even to the stream
is corrupt, we need to exit the loop, they are identical. Is a
copy-and-paste like this the best we can do to add this skip to the
end of the current stream? We would really want to keep the number
of copies of this loop down; we saw a same bug introduced on the
termination condition multiple times to different copies X-.
static void *get_data(unsigned long size)
{
git_zstream stream;
- void *buf = xmalloc(size);
+ void *buf = xmalloc_gentle(size);
+
+ if (!buf) {
+ if (!recover)
+ exit(1);
+ has_errors = 1;
+ inflate_and_throw_away(size);
+ return NULL;
+ }
memset(stream, 0, sizeof(stream));
diff --git a/t/t1050-large.sh b/t/t1050-large.sh
index 5642f84..eec2cca 100755
--- a/t/t1050-large.sh
+++ b/t/t1050-large.sh
@@ -169,4 +169,11 @@ test_expect_success 'fsck' '
test $n -gt 1
'
+test_expect_success 'unpack-objects' '
+ P=`ls .git/objects/pack/*.pack`
+ git unpack-objects -n -r $P 2err
+ test $? = 1
+ grep error: attempting to allocate .* over limit err
+'
+
test_done
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v3 6/6] diff: shortcut for diff'ing two binary SHA-1 objects
Nguyễn Thái Ngọc Duy pclo...@gmail.com writes: diff --git a/t/t1050-large.sh b/t/t1050-large.sh index 711f22c..b294963 100755 --- a/t/t1050-large.sh +++ b/t/t1050-large.sh @@ -116,6 +116,14 @@ test_expect_success 'diff --stat' ' git diff --stat HEAD^ HEAD ' +test_expect_success 'diff' ' + git diff HEAD^ HEAD +' + +test_expect_success 'diff --cached' ' + git diff --cached HEAD^ +' What are these checking? No check for their outcome? test_expect_success 'hash-object' ' git hash-object large1 ' -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v3 6/6] diff: shortcut for diff'ing two binary SHA-1 objects
Nguyễn Thái Ngọc Duy pclo...@gmail.com writes:
If we are given two SHA-1 and asked to determine if they are different
(but not _what_ differences), we know right away by comparing SHA-1.
A side effect of this patch is, because large files are marked binary,
diff-tree will not need to unpack them. 'diff-index --cached' will not
either. But 'diff-files' still does.
Signed-off-by: Nguyễn Thái Ngọc Duy pclo...@gmail.com
---
diff.c | 13 +
t/t1050-large.sh | 8
2 files changed, 21 insertions(+)
diff --git a/diff.c b/diff.c
index d381a6f..b85bcfb 100644
--- a/diff.c
+++ b/diff.c
@@ -2324,6 +2324,19 @@ static void builtin_diff(const char *name_a,
} else if (!DIFF_OPT_TST(o, TEXT)
( (!textconv_one diff_filespec_is_binary(one)) ||
(!textconv_two diff_filespec_is_binary(two)) )) {
+ if (!one-data !two-data
+ S_ISREG(one-mode) S_ISREG(two-mode)
+ !DIFF_OPT_TST(o, BINARY)) {
+ if (!hashcmp(one-sha1, two-sha1)) {
+ if (must_show_header)
+ fprintf(o-file, %s, header.buf);
+ goto free_ab_and_return;
+ }
+ fprintf(o-file, %s, header.buf);
+ fprintf(o-file, %sBinary files %s and %s differ\n,
+ line_prefix, lbl[0], lbl[1]);
+ goto free_ab_and_return;
+ }
A tangent.
I think one and two can point at the same object only when this
filepair is involved in rename/copy. In other words, one and two
with the same mode,sha1,name would not be given to this code. And
must-show-header would be set to true long before we get here in
fill-metainfo in such a case.
I think this new code and the original below which you copied this
one from can probably be simplified. It already felt wrong to see
two copies of fprintf(o-file %s, header.buf) and now we have
four of them. Because this is a copy-and-paste of the identical
logic from below, I do not want you to attempt fixing this tangent
in this patch, though.
Thanks.
if (fill_mmfile(mf1, one) 0 || fill_mmfile(mf2, two) 0)
die(unable to read files to diff);
/* Quite common confusing case */
diff --git a/t/t1050-large.sh b/t/t1050-large.sh
index 711f22c..b294963 100755
--- a/t/t1050-large.sh
+++ b/t/t1050-large.sh
@@ -116,6 +116,14 @@ test_expect_success 'diff --stat' '
git diff --stat HEAD^ HEAD
'
+test_expect_success 'diff' '
+ git diff HEAD^ HEAD
+'
+
+test_expect_success 'diff --cached' '
+ git diff --cached HEAD^
+'
+
test_expect_success 'hash-object' '
git hash-object large1
'
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 23/23] rebase -i: enable options --signoff, --reset-author for pick, reword
Hi, Michael Haggerty writes: On 08/07/2014 01:59 AM, Fabian Ruch wrote: Lift the general unknown option blockade for the pick and reword commands. If `do_cmd` comes across one of the options `--signoff` and `--reset-author` while parsing a to-do entry and the scheduled command is either `pick` or `reword`, relay the option to `do_pick`. The new user-exposed options should be documented in the git-rebase(1) manpage and probably also in the help text that is appended to every rebase -i todo list. The next reroll will add the following paragraph to the git-rebase man page right after the introduction of the 'reword' command in the section INTERACTIVE MODE: The commands pick and reword understand some well-known options. To add a Signed-off-by line at the end of the commit message, pass the `--signoff` option. The authorship can be renewed by specifying the `--reset-author` option. For instance, before you decide to publish a heavily edited commit you might want to reset the authorship and add your signature. You can do so on a per line basis: --- pick deadbee The oneline of this commit pick --reset-author --signoff fa1afe1 The oneline of the next commit ... --- By saying heavily edited commit I tried to describe a commit that has been amended, reworded and reordered in such a way that the actual author information has become meaningless. The help text at the end of every to-do list would look like this: Commands: p, pick = use commit r, reword = use commit, but edit the commit message e, edit = use commit, but stop for amending s, squash = use commit, but meld into previous commit f, fixup = like squash, but discard this commit's log message x, exec = run command (the rest of the line) using shell Options: [pick | reword] --signoff = add a Signed-off-by line [pick | reword] --reset-author = renew authorship These lines can be re-ordered; they are executed from top to bottom. If you remove a line here THAT COMMIT WILL BE LOST. New about this is the Options headline. Fabian -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Git on Mac OS X 10.4.10
Am 14.08.2014 um 16:39 schrieb Torsten Bögershausen: On 08/14/2014 02:13 PM, Markus Hitter wrote: Issue 2: I need this simple patch ... --- compat/apple-common-crypto.h.org2014-07-30 23:19:53.0 +0200 +++ compat/apple-common-crypto.h2014-08-14 12:57:37.0 +0200 @@ -2,7 +2,7 @@ #define OPENSSL_NO_MD5 #define HEADER_HMAC_H #define HEADER_SHA_H -#include CommonCrypto/CommonHMAC.h +//#include CommonCrypto/CommonHMAC.h #define HMAC_CTX CCHmacContext #define HMAC_Init(hmac, key, len, algo) CCHmacInit(hmac, algo, key, len) #define HMAC_Update CCHmacUpdate The CommonCrypto/CommonHMAC.h is in Mac OS X 10.6 .. 10.9, but not in 10.4 (I don't know about 10.5). You can try to tweak the makefiles, search for NO_APPLE_COMMON_CRYPTO, and set NO_APPLE_COMMON_CRYPTO, but only for Darwin 10.3 (or below) Thanks. This: export NO_APPLE_COMMON_CRYPTO=yes make configure CFLAGS=-O2 ./configure --without-tcltk --prefix=/usr/global make all compiles fine on 10.4.10. Would a configure patch checking for the existence of CommonHMAC.h and, if not found, defining this variable, be acceptable? Googling around, it's a bit unclear to me on how to contribute something to Git. Markus -- - - - - - - - - - - - - - - - - - - - Dipl. Ing. (FH) Markus Hitter http://www.jump-ing.de/ -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
You have won 870.000 Euros
Dear Winner, Please kindly go through your attached winning details and reply back for your claim. Lottery promo. Dear Winner.pdf Description: Adobe PDF document
Re: [PATCH v2 1/1] doc: format-patch: don't use origin as a branch name
resending - send mail failure - Original Message - From: Philip Oakley philipoak...@iee.org To: Junio C Hamano gits...@pobox.com Cc: GitList git@vger.kernel.org; Jonathan Nieder jrnie...@gmail.com Sent: Wednesday, August 13, 2014 5:03 PM Subject: Re: [PATCH v2 1/1] doc: format-patch: don't use origin as a branch name From: Junio C Hamano gits...@pobox.com Sent: Tuesday, August 05, 2014 7:19 PM Philip Oakley philipoak...@iee.org writes: From: Junio C Hamano gits...@pobox.com ... Nowhere I am assuming that the reader is creating paches based on wherever someone else had got to. Sorry, but I have no idea what you are complaining about. I think we are talking at cross purposes. My starting point is that (the examples says that) the reader wants to create a patch series for a local branch, relative to their some name branch which they branched from... Perhaps what you are missing is that the 'origin' in that example is not their some name branch. It is how we used to spell what we call 'refs/remotes/origin/HEAD' these days, a copy of their upstream repository's primary branch. Aha, I had a revelation as to where you were coming from in terms of workflow and now see what you were meaning, and how it differed from my perception of the workflow. I've documented the different expectations at the end (for those interested), however of more interest is how the confusion happened and what can be learned from it. We should be ensuring that the examples avoid any such confusion. It can't be assumed that readers appreciate the history of Git so the starting example should be both simple relative to the synopsis and give the any necessary background workflow info. (e.g. the example, relative to Git, could have been from branched from (e.g. the example, relative to Git, could have been from a 'pu' picked up a couple of days earlier, when they'd have said 'git format-patch pu' ;-). Again, if that were a 'pu' picked up a few days earlier, it would not be 'pu', but be 'origin/pu'. We haven't been clear how the branch is 'picked up' which, to me, is partly where the expectation diverged. The other aspect (to me, a more recent learner of git) is that established users were already used to the integrated nature of the remote's DAG, while it's a mental extra step for newer users to link across the 'refs/remotes/name/branch' divide, when a lot of advice is of the type 'don't work on/with remote branches - there be dragons'. The primary reason why 'origin' in the example should be replaced with 'origin/master' is because that is the literal adjustment from the pre-separate-remote world order to today's world order. I was trying to avoid a literal adjustment to what I'd perceived as a presumed workflow. These are examples, showing uses of commands in some hopefully common scenarios. I am not exactly sure what you are aiming at, but if you are trying to strip context and/or background from them and trying to limit them purely to If you do X, Y happens, the resulting description would lack clues that readers rely on in order to choose the usage pattern of the command that is suitable for their situation, which I do not think is a good change to make. The readers would be helped more with You are in state A and want to achieve B. If you do X starting from state A, Y happens, which helps you achieve B., and that is what examples are about. At the moment the example already lacked sufficient context. Now, these where you are and what you want to do may not be explicitly spelled out to avoid redundancy, and it may be an improvement to enhance the scenario without making them too narrow. But that would be a separate change, and renaming 'origin' (whose modern equivalent is 'origin/master' in the context of these examples) to 'master' alone would not do any such enhancement. The local branch 'origin' (more specifically, 'refs/heads/origin') used to be what we used to keep track of 'master' of the upstream, which we use 'refs/remotes/origin/master' these days. Side note: DWIMming origin to remotes/origin/HEAD to remotes/origin/master was invented to keep supporting this 'origin' keeps track of the default upstream convention when we transitioned from the old world order to separate-remote layout. And the reason why 'origin' should not be replaced with 'master' is because your 'master' may already have patches from the topic you are working on, i.e. in your current branch, that the upstream does not yet have. So this a 'develop on master' view, rather than a 'develop on feature branches' approach? Which could explain the misunderstanding. The new work on the feature branches may be merged in 'master' without ever intending to push 'master' out. The development is still done on the topic branches that are merged to your local 'master', perhaps for testing purposes and most likely to personally use it before the upstream picks them up. I suspect your
Re: [PATCH 1/2] fetch: convert argv_gc_auto to struct argv_array
On Thu, Aug 14, 2014 at 06:51:04PM +0700, Nguyễn Thái Ngọc Duy wrote:
- static const char *argv_gc_auto[] = {
- gc, --auto, NULL,
- };
+ struct argv_array argv_gc_auto = ARGV_ARRAY_INIT;
packet_trace_identity(fetch);
@@ -1198,7 +1196,8 @@ int cmd_fetch(int argc, const char **argv, const char
*prefix)
list.strdup_strings = 1;
string_list_clear(list, 0);
- run_command_v_opt(argv_gc_auto, RUN_GIT_CMD);
+ argv_array_pushl(argv_gc_auto, gc, --auto, NULL);
+ run_command_v_opt(argv_gc_auto.argv, RUN_GIT_CMD);
argv_array_clear() here afterwards?
Not a huge deal since we are about to exit, but in the name of
good hygiene.
-Peff
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2/2] fetch: silence git-gc if --quiet is given
On Thu, Aug 14, 2014 at 06:51:05PM +0700, Nguyễn Thái Ngọc Duy wrote: Noticed-by: Matthew Flaschen mflasc...@wikimedia.org Signed-off-by: Nguyễn Thái Ngọc Duy pclo...@gmail.com --- builtin/fetch.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/builtin/fetch.c b/builtin/fetch.c index 9394194..4ff4080 100644 --- a/builtin/fetch.c +++ b/builtin/fetch.c @@ -1197,6 +1197,8 @@ int cmd_fetch(int argc, const char **argv, const char *prefix) string_list_clear(list, 0); argv_array_pushl(argv_gc_auto, gc, --auto, NULL); + if (verbosity 0) + argv_array_push(argv_gc_auto,--quiet); run_command_v_opt(argv_gc_auto.argv, RUN_GIT_CMD); I think this is a fine fix for this specific problem, and we should apply it. But I do wonder if it would be simpler in the long run to treat verbosity as a global option, and pass it around via a GIT_QUIET (or GIT_VERBOSITY) environment variable. I would not be surprised at all to find that there are other cases where sub-programs do not respect the parent verbosity (I know we have had problems with progress reporting flags carried over the transport interface in the past, but I think we fixed all of those). -Peff -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH/RFC] git-imap-send: use libcurl for implementation
Use libcurl's high-level API functions to implement git-imap-send
instead of the previous low-level OpenSSL-based functions.
Since version 7.30.0, libcurl's API has been able to communicate with
IMAP servers. Using those high-level functions instead of the current
ones would reduce imap-send.c by some 1200 lines of code. For now,
the old ones are wrapped in #ifdefs, and the new functions are enabled
by make if curl's version is = 7.35.0, from which version on curl's
CURLOPT_LOGIN_OPTIONS (enabling IMAP authentication) parameter has been
available.
As I don't have access to that many IMAP servers, I haven't been able to
test the new code with a wide variety of parameter combinations. I did
test both secure and insecure (imaps:// and imap://) connections and
values of PLAIN and LOGIN for the authMethod.
Signed-off-by: Bernhard Reiter ock...@raz.or.at
---
Am 2014-08-13 um 03:59 schrieb Jonathan Nieder:
Bernhard Reiter wrote:
[...]
Wow! This sounds lovely. Thanks for working on this.
Well thanks for the friendly welcome and the helpful comments!
I'm attaching a patch where I've applied the fixes you suggested, plus:
* I added the lf_to_crlf conversion to the curl codepath as
communication with another IMAP server I tried was broken without it.
* I added STARTTLS. (That's just the
curl_easy_setopt(curl, CURLOPT_USE_SSL, (long)CURLUSESSL_ALL);
line)
* I tested (and fixed) authentication, i.e. the auth_method stuff. As
the corresponding CURLOPT_LOGIN_OPTIONS flag has only been available
starting with curl 7.35.0, I've bumped the required version to that.
(Apparently it was possible to achieve the same effect with a different
option in between versions 7.31.0 and 7.34.0 [1], but I haven't found
yet how. Is it worth the effort?)
* I made that file scope imap_folder a member of struct imap_server_conf
(named folder), which makes some things easier.
@@ -1417,31 +269,89 @@ int main(int argc, char **argv)
return 1;
}
+curl_global_init(CURL_GLOBAL_ALL);
http.c seems to make the same mistake,
Patch at http://permalink.gmane.org/gmane.comp.version-control.git/255221
[...]
+if (server.tunnel) {
+const char *argv[] = { server.tunnel, NULL };
+struct child_process tunnel = {NULL};
(not about this patch) Could use the child_proccess's internal
argv_array:
struct child_process tunnel = {NULL};
argv_array_push(tunnel.args, server.tunnel);
Patch at
http://permalink.gmane.org/gmane.comp.version-control.git/255220 (The
patch attached to this mail depends on that one.)
No comments on those patches yet, though.
(about this patch) Would there be a way to make this part reuse the
existing code? The only difference I see is that *srvc has been
renamed to server, which doesn't seem to be related to the change of
transport API from OpenSSL to libcurl.
[...]
+curl_socket_t sockfd = tunnel.out; // what about tunnel.in ?
Hmm. curl expects to get a socket it can send(), recv(), setsockopt(),
etc on instead of a pair of fds to read() and write().
I wonder why someone would want to use SSL through a tunnel, though.
Currently it's impossible to get to the SSL codepath when a tunnel
is active (it's in the 'else' block an 'if (srvc-tunnel)'). If that
property is preserved, then we should be safe.
Now this turns out to be the one major annoyance left, because we only
have those two fds (actually pipes, right?), and not a socket that we
could pass to curl, so we can't use it to talk to the IMAP server. So if
the tunnel parameter is set, we're stuck with the old hand-written IMAP
handling routines, even with USE_CURL_FOR_IMAP set, meaning I can't wrap
as much in #ifdef...#endif blocks as I'd like. :-( BTW, due to two of
the blocks that I do add I get a compiler warning about the curl handle
remaining possibly unitialized :-/
I've removed the curl specific socket handling routines, as we can't use
them anyway for now.
I've asked about passing two pipes instead of a socket to curl on their
ML [1] as this has even been discussed before [2], but unfortunately,
there doesn't seem to be a solution as of yet. I've also asked on SO
[3], but no answers yet.
To summarize:
[...]
* As soon as you're ready to roll this out to a wider audience of
testers, let me know, and we can try to get it into shape for
Junio's next branch (and hence Debian experimental).
Is this one good enough already?
Bernhard
[1] http://sourceforge.net/p/curl/bugs/1372/
[2] http://curl.haxx.se/mail/lib-2014-08/0102.html
[3] http://curl.haxx.se/mail/lib-2011-05/0102.html
[4]
http://stackoverflow.com/questions/25306264/connect-in-and-out-pipes-to-network-socket
Documentation/git-imap-send.txt | 3 +-
INSTALL | 15 +++---
Makefile| 16 +-
git.spec.in | 5 +-
imap-send.c | 109
+---
5 files
Re: Git on Mac OS X 10.4.10
Hi Markus, export NO_APPLE_COMMON_CRYPTO=yes make configure CFLAGS=-O2 ./configure --without-tcltk --prefix=/usr/global make all compiles fine on 10.4.10. Would a configure patch checking for the existence of CommonHMAC.h and, if not found, defining this variable, be acceptable? Yes, that sounds useful. Orthogonal to that: a patch to the Darwin section of config.mak.uname so you can build without the 'make configure' would be even more welcome. :) See Documentation/SubmittingPatches for details about how to contribute to git. (Or if you're short on time, see section 5 of that file, Sign your work, and then push your code somewhere and tell us about it.) Thanks, Jonathan -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] gpg-interface: move parse_gpg_output() to where it should be
Earlier, ffb6d7d5 (Move commit GPG signature verification to
commit.c, 2013-03-31) moved this helper that used to be in pretty.c
(i.e. the output code path) to commit.c for better reusability.
It was a good first step in the right direction, but still suffers a
myopic view that commits will be the only thing we would ever want
to sign---we would actually want to be able to reuse it even wider.
The function interprets what GPG said; gpg-interface is obviously a
better place. Move it there.
Signed-off-by: Junio C Hamano gits...@pobox.com
---
commit.c| 36
gpg-interface.c | 36
gpg-interface.h | 17 -
3 files changed, 48 insertions(+), 41 deletions(-)
diff --git a/commit.c b/commit.c
index ae7f2b1..01cdad2 100644
--- a/commit.c
+++ b/commit.c
@@ -1220,42 +1220,6 @@ free_return:
free(buf);
}
-static struct {
- char result;
- const char *check;
-} sigcheck_gpg_status[] = {
- { 'G', \n[GNUPG:] GOODSIG },
- { 'B', \n[GNUPG:] BADSIG },
- { 'U', \n[GNUPG:] TRUST_NEVER },
- { 'U', \n[GNUPG:] TRUST_UNDEFINED },
-};
-
-static void parse_gpg_output(struct signature_check *sigc)
-{
- const char *buf = sigc-gpg_status;
- int i;
-
- /* Iterate over all search strings */
- for (i = 0; i ARRAY_SIZE(sigcheck_gpg_status); i++) {
- const char *found, *next;
-
- if (!skip_prefix(buf, sigcheck_gpg_status[i].check + 1,
found)) {
- found = strstr(buf, sigcheck_gpg_status[i].check);
- if (!found)
- continue;
- found += strlen(sigcheck_gpg_status[i].check);
- }
- sigc-result = sigcheck_gpg_status[i].result;
- /* The trust messages are not followed by key/signer
information */
- if (sigc-result != 'U') {
- sigc-key = xmemdupz(found, 16);
- found += 17;
- next = strchrnul(found, '\n');
- sigc-signer = xmemdupz(found, next - found);
- }
- }
-}
-
void check_commit_signature(const struct commit* commit, struct
signature_check *sigc)
{
struct strbuf payload = STRBUF_INIT;
diff --git a/gpg-interface.c b/gpg-interface.c
index ff07012..3c9624c 100644
--- a/gpg-interface.c
+++ b/gpg-interface.c
@@ -21,6 +21,42 @@ void signature_check_clear(struct signature_check *sigc)
sigc-key = NULL;
}
+static struct {
+ char result;
+ const char *check;
+} sigcheck_gpg_status[] = {
+ { 'G', \n[GNUPG:] GOODSIG },
+ { 'B', \n[GNUPG:] BADSIG },
+ { 'U', \n[GNUPG:] TRUST_NEVER },
+ { 'U', \n[GNUPG:] TRUST_UNDEFINED },
+};
+
+void parse_gpg_output(struct signature_check *sigc)
+{
+ const char *buf = sigc-gpg_status;
+ int i;
+
+ /* Iterate over all search strings */
+ for (i = 0; i ARRAY_SIZE(sigcheck_gpg_status); i++) {
+ const char *found, *next;
+
+ if (!skip_prefix(buf, sigcheck_gpg_status[i].check + 1,
found)) {
+ found = strstr(buf, sigcheck_gpg_status[i].check);
+ if (!found)
+ continue;
+ found += strlen(sigcheck_gpg_status[i].check);
+ }
+ sigc-result = sigcheck_gpg_status[i].result;
+ /* The trust messages are not followed by key/signer
information */
+ if (sigc-result != 'U') {
+ sigc-key = xmemdupz(found, 16);
+ found += 17;
+ next = strchrnul(found, '\n');
+ sigc-signer = xmemdupz(found, next - found);
+ }
+ }
+}
+
void set_signing_key(const char *key)
{
free(configured_signing_key);
diff --git a/gpg-interface.h b/gpg-interface.h
index 37c23da..8d677cc 100644
--- a/gpg-interface.h
+++ b/gpg-interface.h
@@ -5,16 +5,23 @@ struct signature_check {
char *payload;
char *gpg_output;
char *gpg_status;
- char result; /* 0 (not checked),
- * N (checked but no further result),
- * U (untrusted good),
- * G (good)
- * B (bad) */
+
+ /*
+* possible result:
+* 0 (not checked)
+* N (checked but no further result)
+* U (untrusted good)
+* G (good)
+* B (bad)
+*/
+ char result;
char *signer;
char *key;
};
extern void signature_check_clear(struct signature_check *sigc);
+extern void parse_gpg_output(struct signature_check *);
+
extern int sign_buffer(struct strbuf *buffer, struct strbuf *signature, const
char *signing_key);
extern int verify_signed_buffer(const char *payload, size_t payload_size,
const char *signature, size_t
Re: Git on Mac OS X 10.4.10
Markus Hitter m...@jump-ing.de writes: The CommonCrypto/CommonHMAC.h is in Mac OS X 10.6 .. 10.9, but not in 10.4 (I don't know about 10.5). Is this about platform dependency, or what the end user happens to choose to install (in other words, is there an add-on users of 10.4 can choose to add, which allows them to use that header)? -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v3 3/6] unpack-objects: continue when fail to malloc due to large objects
On Thu, Aug 14, 2014 at 11:58 PM, Junio C Hamano gits...@pobox.com wrote:
+static void inflate_and_throw_away(unsigned long size)
+{
But more importantly, the basic structure of this loop is the same
as the loop we already have in the only caller of this new function,
not just the regular zlib produced this much that is not yet the
expected size, go on reading more and we are at the end of the
stream with Z_STREAM_END, and we are done, but even to the stream
is corrupt, we need to exit the loop, they are identical. Is a
copy-and-paste like this the best we can do to add this skip to the
end of the current stream? We would really want to keep the number
of copies of this loop down; we saw a same bug introduced on the
termination condition multiple times to different copies X-.
I know. I'm the author of one of those bugs. I considered updating the
inflate loop in get_data() to support this throw-away mode but was
afraid I may make the same mistake like in index-pack again. I'll
probably drop this patch and think if I can unify inflate loop (for
other places too, not just unpack-objects).
--
Duy
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] unblock and unignore SIGPIPE
Blocked and ignored signals -- but not caught signals -- are inherited
across exec. Some callers with sloppy signal-handling behavior can call
git with SIGPIPE blocked or ignored, even non-deterministically. When
SIGPIPE is blocked or ignored, several git commands can run indefinitely,
ignoring EPIPE returns from write() calls, even when the process that
called them has gone away. Our specific case involved a pipe of git
diff-tree output to a script that reads a limited amount of diff data.
In an ideal world, git would never be called with SIGPIPE blocked or
ignored. But in the real world, several real potential callers, including
Perl, Apache, and Unicorn, sometimes spawn subprocesses with SIGPIPE
ignored. It is easier and more productive to harden git against this
mistake than to clean it up in every potential parent process.
Signed-off-by: Patrick Reynolds patrick.reyno...@github.com
---
cache.h| 1 +
git.c | 5 +
setup.c| 11 +++
t/t0012-sigpipe.sh | 27 +++
4 files changed, 44 insertions(+)
create mode 100755 t/t0012-sigpipe.sh
diff --git a/cache.h b/cache.h
index fcb511d..0a89fc1 100644
--- a/cache.h
+++ b/cache.h
@@ -463,6 +463,7 @@ extern int set_git_dir_init(const char *git_dir, const char
*real_git_dir, int);
extern int init_db(const char *template_dir, unsigned int flags);
extern void sanitize_stdfds(void);
+extern void sanitize_signals(void);
extern int daemonize(void);
#define alloc_nr(x) (((x)+16)*3/2)
diff --git a/git.c b/git.c
index 9c49519..d6b221b 100644
--- a/git.c
+++ b/git.c
@@ -611,6 +611,11 @@ int main(int argc, char **av)
*/
sanitize_stdfds();
+ /*
+* Make sure we aren't ignoring or blocking SIGPIPE.
+*/
+ sanitize_signals();
+
git_setup_gettext();
trace_command_performance(argv);
diff --git a/setup.c b/setup.c
index 0a22f8b..7aa4b01 100644
--- a/setup.c
+++ b/setup.c
@@ -865,3 +865,14 @@ int daemonize(void)
return 0;
#endif
}
+
+/* un-ignore and un-block SIGPIPE */
+void sanitize_signals(void)
+{
+ sigset_t unblock;
+
+ sigemptyset(unblock);
+ sigaddset(unblock, SIGPIPE);
+ sigprocmask(SIG_UNBLOCK, unblock, NULL);
+ signal(SIGPIPE, SIG_DFL);
+}
diff --git a/t/t0012-sigpipe.sh b/t/t0012-sigpipe.sh
new file mode 100755
index 000..213cde3
--- /dev/null
+++ b/t/t0012-sigpipe.sh
@@ -0,0 +1,27 @@
+#!/bin/sh
+
+test_description='check handling of SIGPIPE'
+. ./test-lib.sh
+
+test_expect_success 'create blob' '
+ test-genrandom foo 16384 file
+ git add file
+'
+
+large_git () {
+ for i in $(test_seq 1 100); do
+ git diff --staged --binary || return $?
+ done
+}
+
+test_expect_success 'git dies with SIGPIPE' '
+ OUT=$( ((large_git; echo $? 13) | true) 31 )
+ test $OUT -eq 141
+'
+
+test_expect_success 'git dies with SIGPIPE even if parent ignores it' '
+ OUT=$( ((trap PIPE; large_git; echo $? 13) | true) 31 )
+ test $OUT -eq 141
+'
+
+test_done
--
2.0.1
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
