{"thread":{"id":"4641","subject":"x86 asm SHA1 (draft)","startedAt":"2006-06-23T17:18:09Z","lastAt":"2006-07-03T08:37:44Z","messageCount":45,"participants":["linux@horizon.com","Junio C Hamano","Linus Torvalds","Petr Baudis","Johannes Schindelin","Randal L. Schwartz","Jeff King","Pavel Roskin"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"22370","messageId":"20060623171809.5689.qmail@science.horizon.com","threadId":"4641","inReplyTo":null,"subject":"x86 asm SHA1 (draft)","fromName":"","fromEmail":"linux@horizon.com","sentAt":"2006-06-23T17:18:09Z","receivedAt":"2006-06-23T17:18:09Z","isPatch":false,"sender":{"key":"linux@horizon.com","avatar":null},"body":"As long as I was hacking on PowerPC asm, I figured I might as well take\na crack at the openssl dependency, too. This is a draft x86 SHA1 that\nis a little over 2x faster than the C version on a Pentium M. I haven't\nyet started competing with the OpenSSL code.\n\nThis might be useful for the folks who are careful about licensing and\ndon't like to get mixed up in the OpenSSL/GPL license tangle.\n\nWork in progress, but it functions. Public domain.\n\n\n--- /dev/null\t2006-04-13 05:29:14.000000000 -0400\n+++ sha1x86.S\t2006-06-23 09:14:21.000000000 -0400\n@@ -0,0 +1,233 @@\n+\t.text\n+#define K1 0x5a827999\n+#define K2 0x6ed9eba1\n+#define K3 0x8f1bbcdc\n+#define K4 0xca62c1d6\n+\n+#define A %edi\n+#define B %ebx\n+#define C %ecx\n+#define D %edx\n+#define E %ebp\n+\n+#define T %eax\n+\n+#define MIX(base) \\\n+\tmovl\t60-base(%esp),T;\t\\\n+\txorl\t52-base(%esp),T;\t\\\n+\txorl\t28-base(%esp),T;\t\\\n+\txorl\t8-base(%esp),T;\t\t\\\n+\troll\t$1,T\n+\n+/*\n+ *In these choice functions, C is the value most recently modified\n+ * (It was the B that was rotated in the previous round), so schedule its\n+ * use as late as possible.\n+ */\n+\n+/* Choice function: bitwise b ? c : d = ((d ^ c) & b) ^ d */\n+#define F1(b,c,d,e) \\\n+\tmovl\td,T;\t\\\n+\txorl\tc,T;\t\\\n+\tandl\tb,T;\t\\\n+\troll\t$30,b;\t\\\n+\txorl\td,T;\t\\\n+\taddl\tT,e\n+\n+/* Parity function: b ^ c ^ d = (b ^ d) ^ c */\n+#define F2(b,c,d,e) \\\n+\tmovl\tb,T;\t\\\n+\troll\t$30,b;\t\\\n+\txorl\td,T;\t\\\n+\txorl\tc,T;\t\\\n+\taddl\tT,e\n+\n+/* Majority function: (b&c) | (c&d) | (d&b) = (b&d) + ((b^d)&c) */\n+#define F3(b,c,d,e) \\\n+\tmovl\tb,T;\t\\\n+\tandl\td,T;\t\\\n+\taddl\tT,e;\t\\\n+\tmovl\tb,T;\t\\\n+\troll\t$30,b;\t\\\n+\txorl\td,T;\t\\\n+\tandl\tc,T;\t\\\n+\taddl\tT,e\n+\n+/*\n+ * Register assignments:\n+ * %eax - temp\n+ * %esi - Pointer to input data\n+ * %edi, %ebx, %ecx, %edx, %ebp - A..E\n+ */\n+\n+ /*\n+ * The basic round:\n+ * e += ROTL(e,5) + F(b,c,d) + W[i] + 0x5a827999\n+ */\n+\n+/* This version fetches (and swaps) data from %esi */\n+#define ROUND_LOAD(F,a,b,c,d,e,K) \\\n+\tlodsl;\t\t\\\n+\taddl\t$K,e;\t\\\n+\tbswap\tT;\t\\\n+\taddl\tT,e;\t\\\n+\tpushl\tT;\t\\\n+\tF(b,c,d,e);\t\\\n+\tmovl\ta,T;\t\\\n+\troll\t$5,T;\t\\\n+\taddl\tT,e\n+\n+/* The standard round: compute the new W value and push it on the stack */\n+#define ROUND_MIX(F,a,b,c,d,e,K) \\\n+\tMIX(0);\t\t\\\n+\taddl\t$K,e;\t\\\n+\taddl\tT,e;\t\\\n+\tpushl\tT;\t\\\n+\tF(b,c,d,e);\t\\\n+\tmovl\ta,T;\t\\\n+\troll\t$5,T;\t\\\n+\taddl\tT,e\n+\n+/* Mix the W[] value, but do NOT push it, as it's never used */\n+#define ROUND_LAST(F,a,b,c,d,e,K,base) \\\n+\tMIX(base);\t\\\n+\taddl\t$K,e;\t\\\n+\taddl\tT,e;\t\\\n+\tF(b,c,d,e);\t\\\n+\tmovl\ta,T;\t\\\n+\troll\t$5,T;\t\\\n+\taddl\tT,e\n+\n+/* Args are context (A..E, then a W[] array), then input data */\n+.globl shaHashBlock\n+\t.type\tshaHashBlock, @function\n+shaHashBlock:\n+\tpushl\t%ebp\n+\tpushl\t%ebx\n+\tpushl\t%esi\n+\tpushl\t%edi\n+/* Args now start at 20(%esp) */\n+\n+\tmovl\t20(%esp),T\n+\tmovl\t24(%esp),%esi\n+\n+\tmovl\t (T),A\n+\tmovl\t 4(T),B\n+\tmovl\t 8(T),C\n+\tmovl\t12(T),D\n+\tmovl\t16(T),E\n+\n+\tROUND_LOAD(F1, A,B,C,D,E, K1);\n+\tROUND_LOAD(F1, E,A,B,C,D, K1);\n+\tROUND_LOAD(F1, D,E,A,B,C, K1);\n+\tROUND_LOAD(F1, C,D,E,A,B, K1);\n+\tROUND_LOAD(F1, B,C,D,E,A, K1);\n+\n+\tROUND_LOAD(F1, A,B,C,D,E, K1);\n+\tROUND_LOAD(F1, E,A,B,C,D, K1);\n+\tROUND_LOAD(F1, D,E,A,B,C, K1);\n+\tROUND_LOAD(F1, C,D,E,A,B, K1);\n+\tROUND_LOAD(F1, B,C,D,E,A, K1);\n+\n+\tROUND_LOAD(F1, A,B,C,D,E, K1);\n+\tROUND_LOAD(F1, E,A,B,C,D, K1);\n+\tROUND_LOAD(F1, D,E,A,B,C, K1);\n+\tROUND_LOAD(F1, C,D,E,A,B, K1);\n+\tROUND_LOAD(F1, B,C,D,E,A, K1);\n+\n+\tROUND_LOAD(F1, A,B,C,D,E, K1);\n+\tROUND_MIX(F1, E,A,B,C,D, K1);\n+\tROUND_MIX(F1, D,E,A,B,C, K1);\n+\tROUND_MIX(F1, C,D,E,A,B, K1);\n+\tROUND_MIX(F1, B,C,D,E,A, K1);\n+\n+\tROUND_MIX(F2, A,B,C,D,E, K2);\n+\tROUND_MIX(F2, E,A,B,C,D, K2);\n+\tROUND_MIX(F2, D,E,A,B,C, K2);\n+\tROUND_MIX(F2, C,D,E,A,B, K2);\n+\tROUND_MIX(F2, B,C,D,E,A, K2);\n+\n+\tROUND_MIX(F2, A,B,C,D,E, K2);\n+\tROUND_MIX(F2, E,A,B,C,D, K2);\n+\tROUND_MIX(F2, D,E,A,B,C, K2);\n+\tROUND_MIX(F2, C,D,E,A,B, K2);\n+\tROUND_MIX(F2, B,C,D,E,A, K2);\n+\n+\tROUND_MIX(F2, A,B,C,D,E, K2);\n+\tROUND_MIX(F2, E,A,B,C,D, K2);\n+\tROUND_MIX(F2, D,E,A,B,C, K2);\n+\tROUND_MIX(F2, C,D,E,A,B, K2);\n+\tROUND_MIX(F2, B,C,D,E,A, K2);\n+\n+\tROUND_MIX(F2, A,B,C,D,E, K2);\n+\tROUND_MIX(F2, E,A,B,C,D, K2);\n+\tROUND_MIX(F2, D,E,A,B,C, K2);\n+\tROUND_MIX(F2, C,D,E,A,B, K2);\n+\tROUND_MIX(F2, B,C,D,E,A, K2);\n+\n+\tROUND_MIX(F3, A,B,C,D,E, K3);\n+\tROUND_MIX(F3, E,A,B,C,D, K3);\n+\tROUND_MIX(F3, D,E,A,B,C, K3);\n+\tROUND_MIX(F3, C,D,E,A,B, K3);\n+\tROUND_MIX(F3, B,C,D,E,A, K3);\n+\n+\tROUND_MIX(F3, A,B,C,D,E, K3);\n+\tROUND_MIX(F3, E,A,B,C,D, K3);\n+\tROUND_MIX(F3, D,E,A,B,C, K3);\n+\tROUND_MIX(F3, C,D,E,A,B, K3);\n+\tROUND_MIX(F3, B,C,D,E,A, K3);\n+\n+\tROUND_MIX(F3, A,B,C,D,E, K3);\n+\tROUND_MIX(F3, E,A,B,C,D, K3);\n+\tROUND_MIX(F3, D,E,A,B,C, K3);\n+\tROUND_MIX(F3, C,D,E,A,B, K3);\n+\tROUND_MIX(F3, B,C,D,E,A, K3);\n+\n+\tROUND_MIX(F3, A,B,C,D,E, K3);\n+\tROUND_MIX(F3, E,A,B,C,D, K3);\n+\tROUND_MIX(F3, D,E,A,B,C, K3);\n+\tROUND_MIX(F3, C,D,E,A,B, K3);\n+\tROUND_MIX(F3, B,C,D,E,A, K3);\n+\n+\tROUND_MIX(F2, A,B,C,D,E, K4);\n+\tROUND_MIX(F2, E,A,B,C,D, K4);\n+\tROUND_MIX(F2, D,E,A,B,C, K4);\n+\tROUND_MIX(F2, C,D,E,A,B, K4);\n+\tROUND_MIX(F2, B,C,D,E,A, K4);\n+\n+\tROUND_MIX(F2, A,B,C,D,E, K4);\n+\tROUND_MIX(F2, E,A,B,C,D, K4);\n+\tROUND_MIX(F2, D,E,A,B,C, K4);\n+\tROUND_MIX(F2, C,D,E,A,B, K4);\n+\tROUND_MIX(F2, B,C,D,E,A, K4);\n+\n+\tROUND_MIX(F2, A,B,C,D,E, K4);\n+\tROUND_MIX(F2, E,A,B,C,D, K4);\n+\tROUND_MIX(F2, D,E,A,B,C, K4);\n+\tROUND_MIX(F2, C,D,E,A,B, K4);\n+\tROUND_MIX(F2, B,C,D,E,A, K4);\n+\n+\tROUND_MIX(F2, A,B,C,D,E, K4);\n+\tROUND_MIX(F2, E,A,B,C,D, K4);\n+\tROUND_LAST(F2, D,E,A,B,C, K4, 0);\n+\tROUND_LAST(F2, C,D,E,A,B, K4, 4);\n+\tROUND_LAST(F2, B,C,D,E,A, K4, 8);\n+\n+\taddl\t$77*4,%esp\n+\n+\tmovl\t20(%esp),T\n+\n+\taddl\tA, (T)\n+\taddl\tB, 4(T)\n+\taddl\tC, 8(T)\n+\taddl\tD,12(T)\n+\taddl\tE,16(T)\n+\n+\tpopl\t%edi\n+\tpopl\t%esi\n+\tpopl\t%ebx\n+\tpopl\t%ebp\n+\n+\tret\n+\n+\t.size\tshaHashBlock, .-shaHashBlock\n--- /dev/null\t2006-04-13 05:29:14.000000000 -0400\n+++ sha1asm.h\t2006-06-23 10:24:35.578683250 -0400\n@@ -0,0 +1,12 @@\n+#include \n+#include \t/* For size_t */\n+\n+typedef struct sha_ctx {\n+ uint32_t hash[5];\n+ uint32_t data[16];\n+ uint32_t sizeL, sizeH;\n+} SHA_CTX;\n+\n+void SHA1_Init(SHA_CTX *ctx);\n+void SHA1_Update(SHA_CTX *ctx, const void *dataIn, size_t len);\n+void SHA1_Final(unsigned char hashout[20], SHA_CTX *ctx);\n--- /dev/null\t2006-04-13 05:29:14.000000000 -0400\n+++ sha1asm.c\t2006-06-23 10:25:26.798757250 -0400\n@@ -0,0 +1,163 @@\n+\n+#include \t/* For memcpy */\n+#include \t/* For htonl */\n+\n+#include \"sha1asm.h\"\n+\n+#if ASM\n+extern void shaHashBlock(SHA_CTX *ctx, uint32_t const *input);\n+#else\n+\n+/* \n+ * This chunk of this file are subject to the Mozilla Public\n+ * License Version 1.1 (the \"License\"); you may not use this file\n+ * except in compliance with the License. You may obtain a copy of\n+ * the License at http://www.mozilla.org/MPL/\n+ * \n+ * Software distributed under the License is distributed on an \"AS\n+ * IS\" basis, WITHOUT WARRANTY OF ANY KIND, either express or\n+ * implied. See the License for the specific language governing\n+ * rights and limitations under the License.\n+ * \n+ * The Original Code is SHA 180-1 Reference Implementation (Compact version)\n+ * \n+ * The Initial Developer of the Original Code is Paul Kocher of\n+ * Cryptography Research. Portions created by Paul Kocher are \n+ * Copyright (C) 1995-9 by Cryptography Research, Inc. All\n+ * Rights Reserved.\n+ * \n+ * Contributor(s):\n+ *\n+ * Paul Kocher\n+ * \n+ * Alternatively, this portion of this file may be used under the\n+ * terms of the GNU General Public License Version 2 or later (the\n+ * \"GPL\"), in which case the provisions of the GPL are applicable \n+ * instead of those above. If you wish to allow use of your \n+ * version of this file only under the terms of the GPL and not to\n+ * allow others to use your version of this file under the MPL,\n+ * indicate your decision by deleting the provisions above and\n+ * replace them with the notice and other provisions required by\n+ * the GPL. If you do not delete the provisions above, a recipient\n+ * may use your version of this file under either the MPL or the\n+ * GPL.\n+ */\n+\n+#define ROTL(X,n) (((X) << (n)) | ((X) >> (32-(n))))\n+\n+static void\n+shaHashBlock(SHA_CTX *ctx, uint32_t const *input)\n+{\n+\tint i;\n+\tuint32_t A,B,C,D,E,T;\n+\tuint32_t W[80];\n+\n+\tfor (i = 0; i < 16; i++)\n+\t\tW[i] = ntohl(input[i]);\n+\tfor (i = 16; i < 80; i++) {\n+\t\tT = W[i-3] ^ W[i-8] ^ W[i-14] ^ W[i-16];\n+\t\tW[i] = ROTL(T, 1);\n+\t}\n+\n+\tA = ctx->hash[0];\n+\tB = ctx->hash[1];\n+\tC = ctx->hash[2];\n+\tD = ctx->hash[3];\n+\tE = ctx->hash[4];\n+\n+\tfor (i = 0; i < 20; i++) {\n+\t\tT = ROTL(A,5) + (((C^D)&B)^D) + E + W[i] + 0x5a827999;\n+\t\tE = D; D = C; C = ROTL(B, 30); B = A; A = T;\n+\t}\n+\tfor (i = 20; i < 40; i++) {\n+\t\tT = ROTL(A,5) + (B^C^D) + E + W[i] + 0x6ed9eba1;\n+\t\tE = D; D = C; C = ROTL(B, 30); B = A; A = T;\n+\t}\n+\tfor (i = 40; i < 60; i++) {\n+\t\tT = ROTL(A,5) + (B&C) + (D&(B^C)) + E + W[i] + 0x8f1bbcdc;\n+\t\tE = D; D = C; C = ROTL(B, 30); B = A; A = T;\n+\t}\n+\tfor (i = 60; i < 80; i++) {\n+\t\tT = ROTL(A,5) + (B^C^D) + E + W[i] + 0xca62c1d6;\n+\t\tE = D; D = C; C = ROTL(B, 30); B = A; A = T;\n+\t}\n+\n+\tctx->hash[0] += A;\n+\tctx->hash[1] += B;\n+\tctx->hash[2] += C;\n+\tctx->hash[3] += D;\n+\tctx->hash[4] += E;\n+}\n+#endif\n+\n+/*\n+ * The following part of the file is NOT subject to the above license, and is\n+ * instead placed in the public domain.\n+ */\n+\n+void\n+SHA1_Init(SHA_CTX *ctx)\n+{\n+ /* Initialize H with the magic constants (see FIPS180 for constants)\n+ */\n+ ctx->hash[0] = 0x67452301;\n+ ctx->hash[1] = 0xefcdab89;\n+ ctx->hash[2] = 0x98badcfe;\n+ ctx->hash[3] = 0x10325476;\n+ ctx->hash[4] = 0xc3d2e1f0;\n+\n+ ctx->sizeH = ctx->sizeL = 0;\n+}\n+\n+void\n+SHA1_Update(SHA_CTX *ctx, const void *data, size_t len)\n+{\n+\tunsigned pos = ctx->sizeL % 64;\n+\n+\tctx->sizeL += len;\n+\tctx->sizeH += (ctx->sizeL < (uint32_t)len);\n+\tctx->sizeH += len >> 16 >> 16;\t/* In case size_t is 64 bits */\n+\n+\t/* Leading partial block */\n+\tif (pos) {\n+\t\tunsigned avail = 64 - pos;\n+\t\tif (avail > len)\n+\t\t\tgoto end;\n+\t\tmemcpy((char *)ctx->data + pos, data, avail);\n+\t\tdata = (char const *)data + avail;\n+\t\tlen -= avail;\n+\t\tshaHashBlock(ctx, ctx->data);\n+\t}\n+\t/* Full blocks */\n+\twhile (len >= 64) {\n+\t\tshaHashBlock(ctx, data);\n+\t\tdata = (char const *)data + 64;\n+\t\tlen -= 64;\n+\t}\n+\tpos = 0;\n+end:\n+\t/* Buffer trailing partial block */\n+\tmemcpy((char *)ctx->data + pos, data, len);\n+}\n+\n+void\n+SHA1_Final(unsigned char hashout[20], SHA_CTX *ctx)\n+{\n+ static unsigned char const padding[64] = { 0x80, 0 /* more zeros */ };\n+ uint32_t sizeL = ctx->sizeL;\n+ uint32_t sizeH = ctx->sizeH;\n+ int i;\n+\n+ /* Append final padding, leaving 8 bytes free */\n+ SHA1_Update(ctx, padding, 64 - ((sizeL + 8) % 64));\n+ ctx->data[14] = htonl(sizeH << 3 | sizeL >> 29);\n+ ctx->data[15] = htonl(sizeL << 3);\n+\n+ shaHashBlock(ctx, ctx->data);\n+\n+ for (i = 0; i < 5; i++)\n+ \t((uint32_t *)hashout)[i] = htonl(ctx->hash[i]);\n+\n+ memset(ctx, 0, sizeof *ctx);\n+}\n+\n"},{"id":"22393","messageId":"7vzmg376ee.fsf@assigned-by-dhcp.cox.net","threadId":"4641","inReplyTo":"20060623171809.5689.qmail@science.horizon.com","subject":"Re: x86 asm SHA1 (draft)","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2006-06-24T00:18:33Z","receivedAt":"2006-06-24T00:18:33Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"The series to revamp SHA1 is good but judging the merit of each\nis outside my expertise, so I'd appreciate help to evaluate\nthese changes. For example, I cannot choose between competing\nthree implementations for ppc without having access to a variety\nof ppc machines, and even if I did, ppc is not what I normally\nuse, so incentive to try picking the best one for everybody is\nrelatively low on my part.\n\nWhat we would want are obviously (1) no regression, (2) an easy\nway for people who build git for their own machine to decide\nwhich one suits them the best, and (3) an easy way to tell the\nbuild mechanism to use the one that is chosen.\n\nThe only external interface for the set of SHA1 implementation\nalternatives to the outside world is a well established SHA_CTX\ntype, and three functions SHA1_Init(), SHA1_Update() and\nSHA1_Final(), and the alternative implementations are supposed\nto be drop-in replaceable.\n\nSo let's do something like this:\n\n - When adding a new SHA1 implementation, we need to come up\n with a Makefile symbol (similar to PPC_SHA1, MOZILLA_SHA1 and\n friends) and set up the build machinery to use the one that\n is chosen;\n\n - We need a test program and a build rule in the Makefile that\n links with the chosen SHA1 implementation.\n\n - We need a test script that feeds the above program with known\n vectors to validate the SHA1 implementation (make sure the\n test covers large input to avoid the recent half-gig-limit\n problem), and bench the speed on the platform it was built.\n\n - If we wanted to go fancier, another script that builds all\n applicable alternatives on the building platform, run the\n bench for all of them and automatically pick the right one\n for the platform would be a plus.\n\nWe probably would want to collect the benchmark results from\npopular platforms, have a summary to help people to choose a\nsensible one in the toplevel INSTALL file, and include the raw\nnumbers in Documentation/technical/sha1-implementations.txt.\n\nOnce we go the above path, we may want to include both of the\nthe two new ppc implementations as separate choices as I\nunderstand their performance depends on which ppc you are\ntalking about.\n\nAny takers?\n"},{"id":"22420","messageId":"20060624012202.4822.qmail@science.horizon.com","threadId":"4641","inReplyTo":"7vzmg376ee.fsf@assigned-by-dhcp.cox.net","subject":"Re: x86 asm SHA1 (draft)","fromName":"","fromEmail":"linux@horizon.com","sentAt":"2006-06-24T01:22:02Z","receivedAt":"2006-06-24T01:22:02Z","isPatch":false,"sender":{"key":"linux@horizon.com","avatar":null},"body":"> The series to revamp SHA1 is good but judging the merit of each\n> is outside my expertise, so I'd appreciate help to evaluate\n> these changes. For example, I cannot choose between competing\n> three implementations for ppc without having access to a variety\n> of ppc machines, and even if I did, ppc is not what I normally\n> use, so incentive to try picking the best one for everybody is\n> relatively low on my part.\n\nWell, I'm not sure it's worth this much trouble. Both of my PPC\nimplementations are smaller and faster than the current one,\nso that's a pretty easy decision. The difference between them\nis 2-3%, which is, I think, not enough to be worth the maintenance\nburden of a run-time decision infrastructure. Just pick either one\nand call it a day.\n\n> The only external interface for the set of SHA1 implementation\n> alternatives to the outside world is a well established SHA_CTX\n> type, and three functions SHA1_Init(), SHA1_Update() and\n> SHA1_Final(), and the alternative implementations are supposed\n> to be drop-in replaceable.\n\nI'd prefer it it was an *opaque* SHA_CTX type. Sometimes you can achieve\nsome useful benefits by rearranging the fields. For example, keeping the\n64-bit length field as a native-order 64-bit number when appropriate.\nAnd sometimes it's useful to have the full 80-word W[] array, while\nother implementations don't want it.\n\n> We probably would want to collect the benchmark results from\n> popular platforms, have a summary to help people to choose a\n> sensible one in the toplevel INSTALL file, and include the raw\n> numbers in Documentation/technical/sha1-implementations.txt.\n\nNot that numbers are bad, but I think that until there's a real\nneed for more than a single good-enough version per instruction set,\nthis is excessive. Does hashing even show up on a profile?\n"},{"id":"22423","messageId":"7vfyhv11ej.fsf@assigned-by-dhcp.cox.net","threadId":"4641","inReplyTo":"20060624012202.4822.qmail@science.horizon.com","subject":"Re: x86 asm SHA1 (draft)","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2006-06-24T07:03:00Z","receivedAt":"2006-06-24T07:03:00Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"linux@horizon.com writes:\n\n> Well, I'm not sure it's worth this much trouble. Both of my PPC\n> implementations are smaller and faster than the current one,\n> so that's a pretty easy decision. The difference between them\n> is 2-3%, which is, I think, not enough to be worth the maintenance\n> burden of a run-time decision infrastructure. Just pick either one\n> and call it a day.\n>...\n> Not that numbers are bad, but I think that until there's a real\n> need for more than a single good-enough version per instruction set,\n> this is excessive.\n\nOK. I somehow got an impression that your two versions had\nquite different performance characteristics on G4 and G5 and\nthere was a real choice. If they are between a few per-cent,\nthen I agree it is not worth doing at all.\n"},{"id":"22425","messageId":"7v3bdv0xyd.fsf_-_@assigned-by-dhcp.cox.net","threadId":"4641","inReplyTo":"7vfyhv11ej.fsf@assigned-by-dhcp.cox.net","subject":"From b65bc21e7d8dc8cafc70dfa6354cb66b8874b2d9 Mon Sep 17 00:00:00 2001","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2006-06-24T07:59:49Z","receivedAt":"2006-06-24T07:59:49Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"With this, you can say\n\n\tMOZILLA_SHA1=YesPlease make check-sha1 \n\nto see how fast your favorite SHA-1 implementation is and if it\nfails with small to huge inputs.\n\nSigned-off-by: Junio C Hamano \n---\n\n * As the maintainer, I do need people to see breakage before it\n happens, without having access to all the platforms, hence\n this.\n\n Makefile | 6 ++++\n test-sha1.c | 24 +++++++++++++++++\n test-sha1.sh | 83 ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++\n 3 files changed, 113 insertions(+), 0 deletions(-)\n\ndiff --git a/Makefile b/Makefile\nindex e29e3fa..ea0044d 100644\n--- a/Makefile\n+++ b/Makefile\n@@ -636,6 +636,12 @@ test-delta$X: test-delta.c diff-delta.o \n test-dump-cache-tree$X: dump-cache-tree.o $(GITLIBS)\n \t$(CC) $(ALL_CFLAGS) -o $@ $(ALL_LDFLAGS) $(filter %.o,$^) $(LIBS)\n \n+test-sha1$X: test-sha1.o $(GITLIBS)\n+\t$(CC) $(ALL_CFLAGS) -o $@ $(ALL_LDFLAGS) $(filter %.o,$^) $(LIBS)\n+\n+check-sha1:: test-sha1$X\n+\t./test-sha1.sh\n+\n check:\n \tfor i in *.c; do sparse $(ALL_CFLAGS) $(SPARSE_FLAGS) $$i || exit; done\n \ndiff --git a/test-sha1.c b/test-sha1.c\nnew file mode 100644\nindex 0000000..2efc315\n--- /dev/null\n+++ b/test-sha1.c\n@@ -0,0 +1,24 @@\n+#include \"cache.h\"\n+\n+int main(int ac, char **av)\n+{\n+\tSHA_CTX ctx;\n+\tunsigned char sha1[20];\n+\n+\tSHA1_Init(&ctx);\n+\n+\twhile (1) {\n+\t\tssize_t sz;\n+\t\tchar buffer[8192];\n+\t\tsz = xread(0, buffer, sizeof(buffer));\n+\t\tif (sz == 0)\n+\t\t\tbreak;\n+\t\tif (sz < 0)\n+\t\t\tdie(\"test-sha1: %s\", strerror(errno));\n+\t\tSHA1_Update(&ctx, buffer, sz);\n+\t}\n+\tSHA1_Final(sha1, &ctx);\n+\tputs(sha1_to_hex(sha1));\n+\texit(0);\n+}\n+\ndiff --git a/test-sha1.sh b/test-sha1.sh\nnew file mode 100755\nindex 0000000..01bbb57\n--- /dev/null\n+++ b/test-sha1.sh\n@@ -0,0 +1,83 @@\n+#!/bin/sh\n+\n+dd if=/dev/zero bs=1048576 count=100 2>/dev/null |\n+/usr/bin/time ./test-sha1 >/dev/null\n+\n+while read expect cnt pfx\n+do\n+\tcase \"$expect\" in '#'*) continue ;; esac\n+\tactual=`\n+\t\t{\n+\t\t\ttest -z \"$pfx\" || echo \"$pfx\"\n+\t\t\tdd if=/dev/zero bs=1048576 count=$cnt 2>/dev/null |\n+\t\t\ttr '[\\0]' '[g]'\n+\t\t} | ./test-sha1\n+\t`\n+\tif test \"$expect\" = \"$actual\"\n+\tthen\n+\t\techo \"OK: $expect $cnt $pfx\"\n+\telse\n+\t\techo >&2 \"OOPS: $cnt\"\n+\t\techo >&2 \"expect: $expect\"\n+\t\techo >&2 \"actual: $actual\"\n+\t\texit 1\n+\tfi\n+done </dev/null |\n+\t\t\ttr '[\\0]' '[g]'\n+\t\t} | sha1sum |\n+\t\tsed -e 's/ .*//'\n+\t`\n+\techo \"$actual $cnt $pfx\"\n+done < OK. I somehow got an impression that your two versions had\n> quite different performance characteristics on G4 and G5 and\n> there was a real choice. If they are between a few per-cent,\n> then I agree it is not worth doing at all.\n\nMy apologies for being unclear.\n\nThe place where a noticeable (if not disastrous) difference can appear\nis x86, which has a lot more models with \"interesting\" performance\ncharacteristics. In particular, Intel is fond of building CPUs with a\nvery small \"sweet spot\".\n\nThe openssl SHA1 code had to be reworked to not suck on a P4, with the\nresultant performance change:\n\n# compared with original compared with Intel cc\n# assembler impl. generated code\n# Pentium -16% +48%\n# PIII/AMD +8% +16%\n# P4 +85%(!) +45%\n\nThe original code had the most popular round (what I call\nROUND_MIX(F2,...))) implemented as follows, with single-uop\ninstructions (no load+op) scheduled for the Pentium pipeline:\n(A..E are working variables, S and T are temps)\n\n\tmovl 16(%esp),S\tU \\\n movl 24(%esp),T\t V \\\n xorl S,T\t\tU \\\n movl 48(%esp),S\t V > \"MIX\", pentium-optimized\n xorl S,T\t\tU /\n movl 4(%esp),S\t V /\n xorl S,T\t\tU /\n movl\tB,S\t\t V\n\troll\t$1,T\t\tU\tRotate of mix (SHA0 -> SHA1 fix)\n\txor\tC,S\t\t V\n\tmov\tT,16(%esp)\tU\tStore back W[i]\n\txor\tD,S\t\t V\tFinish computing F(B,C,D) = B^C^D\n\tlea\tK(T,E),E\tU\tAdd K and W[i] to E\n\tmov\tA,T\t\t V\n\troll\t$5,T\t\tUV\n\trorl\t$1,B\t\tU\n\tadd\tS,E\t\t V\n\trorl\t$1,B\t\tU\n\tadd\tT,E\t\t V\n\nWhile the P4-optimized version goes:\n\tmovl\tB,S\n\tmovl\t16(%esp),T\n\trorl\t$2,B\n\txorl\t24(%esp),T\n\txorl\tC,S\n\txorl\t48(%esp),T\n\txorl\tD,S\t\tThis is F(B,C,D) = B^C^D\n\txorl\t4(%esp),T\n\troll\t$1,T\t\tRotate of mix (SHA0 -> SHA1 fix)\n\taddl\tS,E\n\tmovl\tT,16(%esp)\n\tmovl\tA,S\n\troll\t$5,S\n\tlea\tK(E,T),E\n\tadd\tS,E\n\n(The original code actually rotates the working variables around 6\nregisters, not 5, but I've rearranged the last couple of instructions\nto rotate around 5.)\n"},{"id":"22450","messageId":"20060624092921.32165.qmail@science.horizon.com","threadId":"4641","inReplyTo":"7v3bdv0xyd.fsf_-_@assigned-by-dhcp.cox.net","subject":"Re: From b65bc21e7d8dc8cafc70dfa6354cb66b8874b2d9 Mon Sep 17 00:00:00 2001 [PATCH] Makefile: add framework to verify and bench sha1 implementations.","fromName":"","fromEmail":"linux@horizon.com","sentAt":"2006-06-24T09:29:21Z","receivedAt":"2006-06-24T09:29:21Z","isPatch":true,"sender":{"key":"linux@horizon.com","avatar":null},"body":"Nice work, but I might point out that the original PPC SHA bug was hashing\nmore than 0.5G of contiguous data in a *single* call to SHA1_Update,\nwhile your test program works with 8K buffers.\n"},{"id":"22431","messageId":"7vwtb6yip5.fsf@assigned-by-dhcp.cox.net","threadId":"4641","inReplyTo":"7vfyhv11ej.fsf@assigned-by-dhcp.cox.net","subject":"PPC SHA-1 Updates in \"pu\"","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2006-06-24T10:03:02Z","receivedAt":"2006-06-24T10:03:02Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Junio C Hamano writes:\n\n> linux@horizon.com writes:\n>\n>> Well, I'm not sure it's worth this much trouble. Both of my PPC\n>> implementations are smaller and faster than the current one,\n>> so that's a pretty easy decision. The difference between them\n>> is 2-3%, which is, I think, not enough to be worth the maintenance\n>> burden of a run-time decision infrastructure. Just pick either one\n>> and call it a day.\n>>...\n>> Not that numbers are bad, but I think that until there's a real\n>> need for more than a single good-enough version per instruction set,\n>> this is excessive.\n>\n> OK. I somehow got an impression that your two versions had\n> quite different performance characteristics on G4 and G5 and\n> there was a real choice. If they are between a few per-cent,\n> then I agree it is not worth doing at all.\n\nIf somebody has time and inclination, please try updated PPC SHA-1\nfrom linux@horizon.com that is in \"pu\" (say make check-sha1) and\nreport impressions.\n\nThe first line from ./test-sha1.sh is the time output to hash 100MB\nand there should be bunch of OK output to verify the code hashes\nthings correctly for inputs of various sizes.\n"},{"id":"22469","messageId":"Pine.LNX.4.64.0606241147480.6483@g5.osdl.org","threadId":"4641","inReplyTo":"7vwtb6yip5.fsf@assigned-by-dhcp.cox.net","subject":"Re: PPC SHA-1 Updates in \"pu\"","fromName":"Linus Torvalds","fromEmail":"torvalds@osdl.org","sentAt":"2006-06-24T18:55:46Z","receivedAt":"2006-06-24T18:55:46Z","isPatch":false,"sender":{"key":"torvalds@linux-foundation.org","avatar":"https://avatars.githubusercontent.com/u/1024025?v=4"},"body":"\n\nOn Sat, 24 Jun 2006, Junio C Hamano wrote:\n> \n> If somebody has time and inclination, please try updated PPC SHA-1\n> from linux@horizon.com that is in \"pu\" (say make check-sha1) and\n> report impressions.\n\n\"make check-sha1\" passes.\n\nBefore:\n\t[torvalds@g5 linux]$ /usr/bin/time git-fsck-objects --full\n\t101.90user 4.66system 1:46.72elapsed 99%CPU (0avgtext+0avgdata 0maxresident)k\n\t0inputs+0outputs (0major+1787158minor)pagefaults 0swaps\n\nAfter:\n\t[torvalds@g5 linux]$ /usr/bin/time ~/git/git-fsck-objects --full\n\t101.16user 4.32system 1:45.56elapsed 99%CPU (0avgtext+0avgdata 0maxresident)k\n\t0inputs+0outputs (0major+1787127minor)pagefaults 0swaps\n\nwhich doesn't seem to really imply anything seriously changed (in fact, \nrerunning it made the numbers even closer).\n\nThis is on a G5 powerpc.\n\nAlso, \"pu\" in general is totally unusable. It doesn't even compile.\n\nI think that \"Git.xs\" thing is fine for random hacks, but please please \nPLEASE don't make any central program depend on it.\n\n\t\tLinus\n"},{"id":"22473","messageId":"7virmquyin.fsf@assigned-by-dhcp.cox.net","threadId":"4641","inReplyTo":"20060624092921.32165.qmail@science.horizon.com","subject":"Re: From b65bc21e7d8dc8cafc70dfa6354cb66b8874b2d9 Mon Sep 17 00:00:00 2001 [PATCH] Makefile: add framework to verify and bench sha1 implementations.","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2006-06-24T19:47:12Z","receivedAt":"2006-06-24T19:47:12Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"linux@horizon.com writes:\n\n> Nice work, but I might point out that the original PPC SHA bug was hashing\n> more than 0.5G of contiguous data in a *single* call to SHA1_Update,\n> while your test program works with 8K buffers.\n\nBlush. I realized it and updated the version in \"pu\" after I\nsen the message.\n"},{"id":"22477","messageId":"7vhd2atid1.fsf@assigned-by-dhcp.cox.net","threadId":"4641","inReplyTo":"Pine.LNX.4.64.0606241147480.6483@g5.osdl.org","subject":"Re: PPC SHA-1 Updates in \"pu\"","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2006-06-24T20:21:30Z","receivedAt":"2006-06-24T20:21:30Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Linus Torvalds writes:\n\n> Also, \"pu\" in general is totally unusable. It doesn't even compile.\n\nCare to share problems with Pasky and I to take a look at,\nplease?\n\n> I think that \"Git.xs\" thing is fine for random hacks, but please please \n> PLEASE don't make any central program depend on it.\n\nI agree. I got really disgusted when I tentatively pulled the\ncurrent Git.xs into \"next\" and installed it for my own use to\nnotice that it broke git-fmt-merge-msg hence git-pull workflow.\n\nPasky, can we first iron out kinks in the build procedure and\ninstallation before converting existing programs further? The\nthings I worry about currently are:\n\n - the SITELIBARCH gotcha I sent you a message about (and you\n responded to it already -- was that an Acked-by?);\n\n - RPM target -- we probably acquired a new build-dependency in\n which case the .spec file needs to be updated;\n\n - Make sure Git.xs builds and installed result works fine on\n all platforms we care about, including Cygwin and other\n non-Linux boxes.\n\nI'd even suggest we revert the changes to git-fmt-merge-msg to\nkeep it working for now, until the above worries are resolved.\nOtherwise we cannot have it in \"next\" safely (and I REALLY _do_\nwant to have Git.pm infrastructure in \"next\" soonish).\n\nWe can start using Git.xs and friends in some _new_ ancillary\nprograms, once we solve building and installing problems for\neverybody. That way it would help us gain portability and\nconfidence without disrupting existing users.\n"},{"id":"22478","messageId":"Pine.LNX.4.64.0606241338370.6483@g5.osdl.org","threadId":"4641","inReplyTo":"7vhd2atid1.fsf@assigned-by-dhcp.cox.net","subject":"Re: PPC SHA-1 Updates in \"pu\"","fromName":"Linus Torvalds","fromEmail":"torvalds@osdl.org","sentAt":"2006-06-24T20:42:25Z","receivedAt":"2006-06-24T20:42:25Z","isPatch":false,"sender":{"key":"torvalds@linux-foundation.org","avatar":"https://avatars.githubusercontent.com/u/1024025?v=4"},"body":"\n\nOn Sat, 24 Jun 2006, Junio C Hamano wrote:\n\n> Linus Torvalds writes:\n> \n> > Also, \"pu\" in general is totally unusable. It doesn't even compile.\n> \n> Care to share problems with Pasky and I to take a look at,\n> please?\n\nDon't everybody see them?\n\n\tIn file included from Git.xs:8:\n\t../cache.h:6:10: error: #include expects \"FILENAME\" or \n\tIn file included from /usr/lib/perl5/5.8.8/ppc-linux-thread-multi/CORE/perl.h:756,\n\t from Git.xs:15:\n\t/usr/lib/perl5/5.8.8/ppc-linux-thread-multi/CORE/embed.h:4195:1: warning: \"die\" redefined\n\tGit.xs:11:1: warning: this is the location of the previous definition\n\tGit.xs: In function 'boot_Git':\n\tGit.xs:57: warning: passing argument 1 of 'set_error_routine' from incompatible pointer type\n\tGit.xs:58: warning: passing argument 1 of 'set_die_routine' makes qualified function pointer from unqualified\n\tmake[1]: *** [Git.o] Error 1\n\tmake[1]: Leaving directory `/home/torvalds/git/perl'\n\tmake: *** [all] Error 2\n\nhow does that compile for anybody else, when -DSHA1_HEADER isn't set \ncorrectly? The quotes have gone missing:\n\n\t-DSHA1_HEADER='ppc/sha1.h' \n\ndon't ask me why.\n\n\t\tLinus\n"},{"id":"22487","messageId":"7vd5cyt8a3.fsf@assigned-by-dhcp.cox.net","threadId":"4641","inReplyTo":"Pine.LNX.4.64.0606241338370.6483@g5.osdl.org","subject":"Re: PPC SHA-1 Updates in \"pu\"","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2006-06-24T23:59:16Z","receivedAt":"2006-06-24T23:59:16Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Linus Torvalds writes:\n\n> Don't everybody see them?\n\nNo. But I see it now.\n\n> how does that compile for anybody else, when -DSHA1_HEADER isn't set \n> correctly? The quotes have gone missing:\n>\n> \t-DSHA1_HEADER='ppc/sha1.h' \n>\n> don't ask me why.\n\nThat is, as usual, caused by careless shell quoting.\n\n : gitster; PPC_SHA1=YesPlease Meta/Make perl/Makefile\n GIT_VERSION = 1.4.1.rc1.g9adbe\n (cd perl && /usr/bin/perl Makefile.PL \\\n PREFIX=\"/home/junio/git-test\" \\\n DEFINE=\"-O2 -Wall -Wdeclaration-after-statement\n -g -fPIC -DSHA1_HEADER='\"ppc/sha1.h\"'\n -DGIT_VERSION=\\\\\\\"1.4.1.rc1.g9adbe\\\\\\\"\" \\\n LIBS=\"libgit.a xdiff/lib.a -lz\")\n Unrecognized argument in LIBS ignored: 'libgit.a'\n Unrecognized argument in LIBS ignored: 'xdiff/lib.a'\n Writing Makefile for Git\n\nAll options but to use OpenSSL SHA-1 implementation share the\nsame problem (Meta/Make is a thin \"make\" wrapper to give USE_PIC\nand other C compilation flags):\n\n : gitster; ARM_SHA1=YesPlease Meta/Make perl/Makefile\n (cd perl && /usr/bin/perl Makefile.PL \\\n PREFIX=\"/home/junio/git-test\" \\\n DEFINE=\"-O2 -Wall -Wdeclaration-after-statement\n -g -fPIC -DSHA1_HEADER='\"arm/sha1.h\"'\n -DGIT_VERSION=\\\\\\\"1.4.1.rc1.g9adbe\\\\\\\"\" \\\n LIBS=\"libgit.a xdiff/lib.a -lz\")\n Unrecognized argument in LIBS ignored: 'libgit.a'\n Unrecognized argument in LIBS ignored: 'xdiff/lib.a'\n Writing Makefile for Git\n\n : gitster; MOZILLA_SHA1=YesPlease Meta/Make perl/Makefile\n (cd perl && /usr/bin/perl Makefile.PL \\\n PREFIX=\"/home/junio/git-test\" \\\n DEFINE=\"-O2 -Wall -Wdeclaration-after-statement\n -g -fPIC -DSHA1_HEADER='\"mozilla-sha1/sha1.h\"'\n -DGIT_VERSION=\\\\\\\"1.4.1.rc1.g9adbe\\\\\\\"\" \\\n LIBS=\"libgit.a xdiff/lib.a -lz\")\n Unrecognized argument in LIBS ignored: 'libgit.a'\n Unrecognized argument in LIBS ignored: 'xdiff/lib.a'\n Writing Makefile for Git\n"},{"id":"22488","messageId":"20060625010202.GX21864@pasky.or.cz","threadId":"4641","inReplyTo":"7vd5cyt8a3.fsf@assigned-by-dhcp.cox.net","subject":"Re: PPC SHA-1 Updates in \"pu\"","fromName":"Petr Baudis","fromEmail":"pasky@suse.cz","sentAt":"2006-06-25T01:02:02Z","receivedAt":"2006-06-25T01:02:02Z","isPatch":false,"sender":{"key":"pasky@ucw.cz","avatar":"https://avatars.githubusercontent.com/u/18439?v=4"},"body":"Dear diary, on Sun, Jun 25, 2006 at 01:59:16AM CEST, I got a letter\nwhere Junio C Hamano said that...\n> Linus Torvalds writes:\n> \n> > how does that compile for anybody else, when -DSHA1_HEADER isn't set \n> > correctly? The quotes have gone missing:\n> >\n> > \t-DSHA1_HEADER='ppc/sha1.h' \n> >\n> > don't ask me why.\n> \n> That is, as usual, caused by careless shell quoting.\n> \n> : gitster; PPC_SHA1=YesPlease Meta/Make perl/Makefile\n> GIT_VERSION = 1.4.1.rc1.g9adbe\n> (cd perl && /usr/bin/perl Makefile.PL \\\n> PREFIX=\"/home/junio/git-test\" \\\n> DEFINE=\"-O2 -Wall -Wdeclaration-after-statement\n> -g -fPIC -DSHA1_HEADER='\"ppc/sha1.h\"'\n> -DGIT_VERSION=\\\\\\\"1.4.1.rc1.g9adbe\\\\\\\"\" \\\n> LIBS=\"libgit.a xdiff/lib.a -lz\")\n> Unrecognized argument in LIBS ignored: 'libgit.a'\n> Unrecognized argument in LIBS ignored: 'xdiff/lib.a'\n> Writing Makefile for Git\n\nOops...\n\n----\n\nGit.pm build: Fix $DEFINE quoting and missing GIT-CFLAGS dependency\n\nSigned-off-by: Petr Baudis \n\ndiff --git a/Makefile b/Makefile\nindex 9a59466..64375f6 100644\n--- a/Makefile\n+++ b/Makefile\n@@ -608,10 +608,12 @@ XDIFF_OBJS=xdiff/xdiffi.o xdiff/xprepare\n \trm -f $@ && $(AR) rcs $@ $(XDIFF_OBJS)\n \n \n-perl/Makefile:\tperl/Git.pm perl/Makefile.PL\n+PERL_DEFINES = $(ALL_CFLAGS) -DGIT_VERSION='\"$(GIT_VERSION)\"'\n+PERL_DEFINES_SQ = $(subst ','\\'',$(PERL_DEFINES))\n+perl/Makefile:\tperl/Git.pm perl/Makefile.PL GIT-CFLAGS\n \t(cd perl && $(PERL_PATH) Makefile.PL \\\n \t\tPREFIX=\"$(prefix)\" \\\n-\t\tDEFINE=\"$(ALL_CFLAGS) -DGIT_VERSION=\\\\\\\"$(GIT_VERSION)\\\\\\\"\" \\\n+\t\tDEFINE='$(PERL_DEFINES_SQ)' \\\n \t\tLIBS=\"$(EXTLIBS)\")\n \n doc:\n\n-- \n\t\t\t\tPetr \"Pasky\" Baudis\nStuff: http://pasky.or.cz/\nA person is just about as big as the things that make them angry.\n"},{"id":"22491","messageId":"20060625012435.GZ21864@pasky.or.cz","threadId":"4641","inReplyTo":"7vhd2atid1.fsf@assigned-by-dhcp.cox.net","subject":"Re: PPC SHA-1 Updates in \"pu\"","fromName":"Petr Baudis","fromEmail":"pasky@suse.cz","sentAt":"2006-06-25T01:24:35Z","receivedAt":"2006-06-25T01:24:35Z","isPatch":false,"sender":{"key":"pasky@ucw.cz","avatar":"https://avatars.githubusercontent.com/u/18439?v=4"},"body":"Dear diary, on Sat, Jun 24, 2006 at 10:21:30PM CEST, I got a letter\nwhere Junio C Hamano said that...\n> Pasky, can we first iron out kinks in the build procedure and\n> installation before converting existing programs further?\n\nSure.\n\n> The things I worry about currently are:\n> \n> - the SITELIBARCH gotcha I sent you a message about (and you\n> responded to it already -- was that an Acked-by?);\n\nYes. :-)\n\n> - RPM target -- we probably acquired a new build-dependency in\n> which case the .spec file needs to be updated;\n\nWell, perl is currently not listed even as a runtime dependency,\nso does it really need to be listed as a build dependency?\n\n> - Make sure Git.xs builds and installed result works fine on\n> all platforms we care about, including Cygwin and other\n> non-Linux boxes.\n\nUnfortunately I don't have access to a lot of those. :-(\n\n> I'd even suggest we revert the changes to git-fmt-merge-msg to\n> keep it working for now, until the above worries are resolved.\n> Otherwise we cannot have it in \"next\" safely (and I REALLY _do_\n> want to have Git.pm infrastructure in \"next\" soonish).\n\nYes, that sounds reasonable.\n\n> We can start using Git.xs and friends in some _new_ ancillary\n> programs, once we solve building and installing problems for\n> everybody. That way it would help us gain portability and\n> confidence without disrupting existing users.\n\nWell, I don't think it's very likely that Git.pm per se would be buggy\non a certain specific platform - it should either work as well as\neverywhere else or not build at all, in which case you have disrupted\nthe existing users anyway. :-) (But without disrupting anyone we won't\nget any bugreports and never get it fixed.)\n\nPerhaps other converted perl scripts can linger at least on the pu\nbranch?\n\n-- \n\t\t\t\tPetr \"Pasky\" Baudis\nStuff: http://pasky.or.cz/\nA person is just about as big as the things that make them angry.\n"},{"id":"22497","messageId":"20060625014009.GA21864@pasky.or.cz","threadId":"4641","inReplyTo":"20060625010202.GX21864@pasky.or.cz","subject":"[PATCH] Git.pm build: Fix quoting and missing GIT-CFLAGS dependency","fromName":"Petr Baudis","fromEmail":"pasky@suse.cz","sentAt":"2006-06-25T01:40:09Z","receivedAt":"2006-06-25T01:40:09Z","isPatch":true,"sender":{"key":"pasky@ucw.cz","avatar":"https://avatars.githubusercontent.com/u/18439?v=4"},"body":"Signed-off-by: Petr Baudis \n---\n\n This one should do a better job; if we quote, let's do it proper. :-)\n\n Makefile | 12 ++++++++----\n 1 files changed, 8 insertions(+), 4 deletions(-)\n\ndiff --git a/Makefile b/Makefile\nindex 9a59466..fb9ffad 100644\n--- a/Makefile\n+++ b/Makefile\n@@ -608,11 +608,15 @@ XDIFF_OBJS=xdiff/xdiffi.o xdiff/xprepare\n \trm -f $@ && $(AR) rcs $@ $(XDIFF_OBJS)\n \n \n-perl/Makefile:\tperl/Git.pm perl/Makefile.PL\n+PERL_DEFINE = $(ALL_CFLAGS) -DGIT_VERSION='\"$(GIT_VERSION)\"'\n+PERL_DEFINE_SQ = $(subst ','\\'',$(PERL_DEFINE))\n+PERL_LIBS = $(EXTLIBS)\n+PERL_LIBS_SQ = $(subst ','\\'',$(PERL_LIBS))\n+perl/Makefile:\tperl/Git.pm perl/Makefile.PL GIT-CFLAGS\n \t(cd perl && $(PERL_PATH) Makefile.PL \\\n-\t\tPREFIX=\"$(prefix)\" \\\n-\t\tDEFINE=\"$(ALL_CFLAGS) -DGIT_VERSION=\\\\\\\"$(GIT_VERSION)\\\\\\\"\" \\\n-\t\tLIBS=\"$(EXTLIBS)\")\n+\t\tPREFIX='$(prefix_SQ)' \\\n+\t\tDEFINE='$(PERL_DEFINE_SQ)' \\\n+\t\tLIBS='$(PERL_LIBS)')\n \n doc:\n \t$(MAKE) -C Documentation all\n\n-- \n\t\t\t\tPetr \"Pasky\" Baudis\nStuff: http://pasky.or.cz/\nA person is just about as big as the things that make them angry.\n"},{"id":"22512","messageId":"7vac82q6mb.fsf@assigned-by-dhcp.cox.net","threadId":"4641","inReplyTo":"20060625014009.GA21864@pasky.or.cz","subject":"Re: [PATCH] Git.pm build: Fix quoting and missing GIT-CFLAGS dependency","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2006-06-25T03:03:24Z","receivedAt":"2006-06-25T03:03:24Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Petr Baudis writes:\n\n> This one should do a better job; if we quote, let's do it proper. :-)\n>\n> +PERL_DEFINE = $(ALL_CFLAGS) -DGIT_VERSION='\"$(GIT_VERSION)\"'\n> +PERL_DEFINE_SQ = $(subst ','\\'',$(PERL_DEFINE))\n> +PERL_LIBS = $(EXTLIBS)\n> +PERL_LIBS_SQ = $(subst ','\\'',$(PERL_LIBS))\n> +perl/Makefile:\tperl/Git.pm perl/Makefile.PL GIT-CFLAGS\n> \t(cd perl && $(PERL_PATH) Makefile.PL \\\n> +\t\tPREFIX='$(prefix_SQ)' \\\n> +\t\tDEFINE='$(PERL_DEFINE_SQ)' \\\n> +\t\tLIBS='$(PERL_LIBS)')\n\nYes let's ;-). You obviously meant PERL_LIBS_SQ on the last line.\n\nDuring our a handful piecemeal patch exchange back-and-forth on\nthe list, most of the patches did not apply mechanically, so I\nrolled them up and have pushed out the result in \"pu\" and it\nwill mirror out shortly. I am reasonably sure it is in much\nbetter shape than 24 hours ago; could you double check the\nresult for me please?\n\nAnd I earlier said...\n\n Pasky, can we first iron out kinks in the build procedure and\n installation before converting existing programs further? The\n things I worry about currently are:\n\n - the SITELIBARCH gotcha I sent you a message about (and you\n responded to it already -- was that an Acked-by?);\n\n - RPM target -- we probably acquired a new build-dependency in\n which case the .spec file needs to be updated;\n\n - Make sure Git.xs builds and installed result works fine on\n all platforms we care about, including Cygwin and other\n non-Linux boxes.\n\n I'd even suggest we revert the changes to git-fmt-merge-msg to\n keep it working for now, until the above worries are resolved.\n Otherwise we cannot have it in \"next\" safely (and I REALLY _do_\n want to have Git.pm infrastructure in \"next\" soonish).\n\n We can start using Git.xs and friends in some _new_ ancillary\n programs, once we solve building and installing problems for\n everybody. That way it would help us gain portability and\n confidence without disrupting existing users.\n\nI think we have cleared SITELIBARCH, and Git.xs building is in\ntestable state for wider audience. The remaining hurdles are to\nmake sure the RPM target is still sensible, and fix the test\nscheme.\n\nNow, I am clueless about RPM, so help is very much appreciated.\n\nAbout the testsuite, I think with the way git-fmt-merge-msg (and\nother Perl scripts that will use Git.pm) is munged on the\ninitial line \"#!/usr/bin/perl -I$(installedpath)\", the test\nscheme is seriously broken. To see how yourself, have a good\nworking version of Git.pm and friends in the path your\ngit-fmt-merge-msg's first line points at, apply the following\npatch to perl/Git.pm in your source tree and run \"make test\".\nIt will pass t5700-clone-reference.sh test, which does \"git\npull\" (and uses git-fmt-merge-msg) without problems X-<.\n\ndiff --git a/perl/Git.pm b/perl/Git.pm\nindex 7bbb5be..c9121f4 100644\n--- a/perl/Git.pm\n+++ b/perl/Git.pm\n@@ -1,3 +1,5 @@\n+syntax error\n+\n =head1 NAME\n \n Git - Perl interface to the Git version control system\n\nThis is (as I said in a separate message earlier) because -I on\nthe first line (and the command line) seems to take precedence\nover PERL5LIB we set up in the test harness, so the test does\nnot find the broken version you think you are testing. And\nafter it tests out OK, you install it and suffer from the\nbreakage. This is bad.\n\nI am not sure what the right way to fix it, though. Obviously,\nwe could do something like the following:\n\ndiff --git a/Makefile b/Makefile\nindex 3a67578..3350be3 100644\n--- a/Makefile\n+++ b/Makefile\n@@ -517,9 +517,12 @@ common-cmds.h: Documentation/git-*.txt\n \tchmod +x $@+\n \tmv $@+ $@\n \n-$(patsubst %.perl,%,$(SCRIPT_PERL)) : % : %.perl\n+$(patsubst %.perl,%,$(SCRIPT_PERL)): perl/Makefile\n+$(patsubst %.perl,%,$(SCRIPT_PERL)): % : %.perl\n \trm -f $@ $@+\n-\tsed -e '1s|#!.*perl\\(.*\\)|#!$(PERL_PATH_SQ)\\1 -I'\"$$(make -s -C perl instlibdir)\"'|' \\\n+\tINSTLIBDIR=$$(make -s -C perl instlibdir) && \\\n+\tsed -e '1s|#!.*perl\\(.*\\)|#!$(PERL_PATH_SQ)\\1|' \\\n+\t -e 's|@@INSTLIBDIR@@|'\"$$INSTLIBDIR\"'|g' \\\n \t -e 's/@@GIT_VERSION@@/$(GIT_VERSION)/g' \\\n \t $@.perl >$@+\n \tchmod +x $@+\ndiff --git a/git-fmt-merge-msg.perl b/git-fmt-merge-msg.perl\nindex f86231e..e8fad02 100755\n--- a/git-fmt-merge-msg.perl\n+++ b/git-fmt-merge-msg.perl\n@@ -5,6 +5,7 @@ #\n # Read .git/FETCH_HEAD and make a human readable merge message\n # by grouping branches and tags together to form a single line.\n \n+unshift @INC, '@@INSTLIBDIR@@';\n use strict;\n use Git;\n use Error qw(:try);\n\nwhich is in line with what git-merge-recursive does, but it is\nnot really what usual Perl modules and scripts do. It is\nbending backwards to support testing which does not feel right.\n\nThe additional dependency to perl/Makefile is needed regardless\nof this tentative fix -- you cannot run make -C perl before\nbuilding perl/Makefile.\n"},{"id":"22520","messageId":"7vfyhtopjm.fsf@assigned-by-dhcp.cox.net","threadId":"4641","inReplyTo":"20060625012435.GZ21864@pasky.or.cz","subject":"Re: PPC SHA-1 Updates in \"pu\"","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2006-06-25T03:57:33Z","receivedAt":"2006-06-25T03:57:33Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Petr Baudis writes:\n\n>> - RPM target -- we probably acquired a new build-dependency in\n>> which case the .spec file needs to be updated;\n>\n> Well, perl is currently not listed even as a runtime dependency,\n> so does it really need to be listed as a build dependency?\n\nReally? I think rpmbuild is getting anything that matches \"^use \"\nand listing the perl modules as dependencies.\n\n>> - Make sure Git.xs builds and installed result works fine on\n>> all platforms we care about, including Cygwin and other\n>> non-Linux boxes.\n>\n> Unfortunately I don't have access to a lot of those. :-(\n\nI don't either. That's why I would want to place something\nlow-impact on \"next\" to ask help from the users.\n\n>> I'd even suggest we revert the changes to git-fmt-merge-msg to\n>> keep it working for now, until the above worries are resolved.\n>> Otherwise we cannot have it in \"next\" safely (and I REALLY _do_\n>> want to have Git.pm infrastructure in \"next\" soonish).\n>\n> Yes, that sounds reasonable.\n>\n>> We can start using Git.xs and friends in some _new_ ancillary\n>> programs, once we solve building and installing problems for\n>> everybody. That way it would help us gain portability and\n>> confidence without disrupting existing users.\n>\n> Well, I don't think it's very likely that Git.pm per se would be buggy\n> on a certain specific platform - it should either work as well as\n> everywhere else or not build at all, in which case you have disrupted\n> the existing users anyway. :-) (But without disrupting anyone we won't\n> get any bugreports and never get it fixed.)\n>\n> Perhaps other converted perl scripts can linger at least on the pu\n> branch?\n\nMy preference is to keep your other conversion in \"later\"\nmailbox, not even in \"pu\", to keep them from distracting me.\nI'd like to have something low-impact (e.g. \"git-mv\" which I do\nnot use and I do not think Linus uses) along with the perl/\ndirectory and build procedure in \"next\" soonish to make sure at\nleast things build and correctly install for everybody\n(compiling and linking alone would not count as \"correctly\ninstall\" while we have something like INSTALLSITEARCH gotcha).\nAfter we are reasonably confident about the whole .xs stuff we\ncan revert the revert of git-fmt-merge-msg.\n"},{"id":"22531","messageId":"20060625093444.GD21864@pasky.or.cz","threadId":"4641","inReplyTo":"7vfyhtopjm.fsf@assigned-by-dhcp.cox.net","subject":"Re: PPC SHA-1 Updates in \"pu\"","fromName":"Petr Baudis","fromEmail":"pasky@suse.cz","sentAt":"2006-06-25T09:34:44Z","receivedAt":"2006-06-25T09:34:44Z","isPatch":false,"sender":{"key":"pasky@ucw.cz","avatar":"https://avatars.githubusercontent.com/u/18439?v=4"},"body":"Dear diary, on Sun, Jun 25, 2006 at 05:57:33AM CEST, I got a letter\nwhere Junio C Hamano said that...\n> Petr Baudis writes:\n> \n> >> - RPM target -- we probably acquired a new build-dependency in\n> >> which case the .spec file needs to be updated;\n> >\n> > Well, perl is currently not listed even as a runtime dependency,\n> > so does it really need to be listed as a build dependency?\n> \n> Really? I think rpmbuild is getting anything that matches \"^use \"\n> and listing the perl modules as dependencies.\n\nI had on my mind to depend only on modules that are part of the default\nPerl distribution, since installing them from CPAN is a bother if you\nare installing Git to your home directory. That is why we bundle Error.\n\nAll the modules we depend on should come bundled with Perl since 5.8.1.\nNow, I'm not sure what our \"cutoff\" point is, and even if it is\nsomething like 5.6.0 whether we can just require users of Perl older\nthan 5.8.1 (which should be only some rare and obscure systems anyway)\nto install the modules from CPAN.\n\nIf not, we can just get rid of Scalar::Util and XSLoader and we should\nbe clean; XSLoader should be easy, Scalar::Util somewhat more messy\nsince we will have to get Error.pm own .xs as well.\n\n-- \n\t\t\t\tPetr \"Pasky\" Baudis\nStuff: http://pasky.or.cz/\nA person is just about as big as the things that make them angry.\n"},{"id":"22534","messageId":"Pine.LNX.4.63.0606251202320.29667@wbgn013.biozentrum.uni-wuerzburg.de","threadId":"4641","inReplyTo":"20060625093444.GD21864@pasky.or.cz","subject":"Re: PPC SHA-1 Updates in \"pu\"","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2006-06-25T10:07:21Z","receivedAt":"2006-06-25T10:07:21Z","isPatch":false,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi,\n\nOn Sun, 25 Jun 2006, Petr Baudis wrote:\n\n> All the modules we depend on should come bundled with Perl since 5.8.1.\n> Now, I'm not sure what our \"cutoff\" point is, and even if it is\n> something like 5.6.0 whether we can just require users of Perl older\n> than 5.8.1 (which should be only some rare and obscure systems anyway)\n> to install the modules from CPAN.\n\nNO! It is _wrong_ to require users to upgrade, when a little more work on \nour side would fix it. Requiring users to upgrade is a proactive way to \nget rid of new users.\n\nAnd old ones. If you would require me to upgrade to Perl 5.8.1, I would \nrather stop upgrading git. Hell, something I really like about git: I just \ndownload the tar.gz, unpack it, and type make install. And usually that \nJust Works. (Except MinGW32, but I have already managed to see a nice \n\"git-log -p\" with it.)\n\nCiao,\nDscho\n"},{"id":"22538","messageId":"20060625102037.GI29364@pasky.or.cz","threadId":"4641","inReplyTo":"Pine.LNX.4.63.0606251202320.29667@wbgn013.biozentrum.uni-wuerzburg.de","subject":"Re: PPC SHA-1 Updates in \"pu\"","fromName":"Petr Baudis","fromEmail":"pasky@suse.cz","sentAt":"2006-06-25T10:20:37Z","receivedAt":"2006-06-25T10:20:37Z","isPatch":false,"sender":{"key":"pasky@ucw.cz","avatar":"https://avatars.githubusercontent.com/u/18439?v=4"},"body":" Hi,\n\nDear diary, on Sun, Jun 25, 2006 at 12:07:21PM CEST, I got a letter\nwhere Johannes Schindelin said that...\n> On Sun, 25 Jun 2006, Petr Baudis wrote:\n> \n> > All the modules we depend on should come bundled with Perl since 5.8.1.\n> > Now, I'm not sure what our \"cutoff\" point is, and even if it is\n> > something like 5.6.0 whether we can just require users of Perl older\n> > than 5.8.1 (which should be only some rare and obscure systems anyway)\n> > to install the modules from CPAN.\n> \n> NO! It is _wrong_ to require users to upgrade, when a little more work on \n> our side would fix it. Requiring users to upgrade is a proactive way to \n> get rid of new users.\n> \n> And old ones. If you would require me to upgrade to Perl 5.8.1, I would \n> rather stop upgrading git.\n\n please read it again - I'm not requiring you to upgrade to Perl 5.8.1.\nI'm just saying that if you have Perl older than 5.8.1, you might need\nto install some extra modules from CPAN.\n\n Now, if that's not acceptable either that's fine by me and I can\nadapt, I just need to know at which point we _will_ require you to\nupgrade or install extra modules.\n\n-- \n\t\t\t\tPetr \"Pasky\" Baudis\nStuff: http://pasky.or.cz/\nA person is just about as big as the things that make them angry.\n"},{"id":"22540","messageId":"7vzmg1v7ci.fsf@assigned-by-dhcp.cox.net","threadId":"4641","inReplyTo":"20060625102037.GI29364@pasky.or.cz","subject":"Re: PPC SHA-1 Updates in \"pu\"","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2006-06-25T10:48:45Z","receivedAt":"2006-06-25T10:48:45Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Petr Baudis writes:\n\n>> And old ones. If you would require me to upgrade to Perl 5.8.1, I would \n>> rather stop upgrading git.\n>\n> please read it again - I'm not requiring you to upgrade to Perl 5.8.1.\n> I'm just saying that if you have Perl older than 5.8.1, you might need\n> to install some extra modules from CPAN.\n>\n> Now, if that's not acceptable either that's fine by me and I can\n> adapt, I just need to know at which point we _will_ require you to\n> upgrade or install extra modules.\n\nI vaguely recall that last time we discussed the minimum Perl\nversion requirement somebody perhaps Merlyn said 5.6 is old\nenough but in some corporate settings people may still be stuck\nwith 5.004.\n\nTentatively let's say our cut-off point is somewhere around 5.6.\nIf we can get away without relying on extra from CPAN that would\nbe great. Otherwise as long as the modules from CPAN we end up\ndepending on are all compatible with the cut-off version of Perl\nthat would be acceptable. We might even try to be nicer and\ncarry a straight copy of what we require from CPAN in compat/\njust like we have subprocess.py there (modulo licensing worries\nif any, of course).\n\nJohannes, Linus and the list, would that be a good enough\nguideline?\n"},{"id":"22556","messageId":"Pine.LNX.4.63.0606251537450.29667@wbgn013.biozentrum.uni-wuerzburg.de","threadId":"4641","inReplyTo":"7vzmg1v7ci.fsf@assigned-by-dhcp.cox.net","subject":"Re: PPC SHA-1 Updates in \"pu\"","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2006-06-25T13:44:29Z","receivedAt":"2006-06-25T13:44:29Z","isPatch":false,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi,\n\nOn Sun, 25 Jun 2006, Junio C Hamano wrote:\n\n> I vaguely recall that last time we discussed the minimum Perl\n> version requirement somebody perhaps Merlyn said 5.6 is old\n> enough but in some corporate settings people may still be stuck\n> with 5.004.\n> \n> Tentatively let's say our cut-off point is somewhere around 5.6.\n> If we can get away without relying on extra from CPAN that would\n> be great. Otherwise as long as the modules from CPAN we end up\n> depending on are all compatible with the cut-off version of Perl\n> that would be acceptable. We might even try to be nicer and\n> carry a straight copy of what we require from CPAN in compat/\n> just like we have subprocess.py there (modulo licensing worries\n> if any, of course).\n\nI can live with it. Although I still think that it would be a good idea to \nconvert (at least the most commonly used) scripts to C.\n\nPerl, Python and sometimes even bash are good for fast prototyping. But \nfor serious work, such as profiling, they are not that good.\n\nAnd you can see different behaviour on different platforms (plus things \nlike the SunCC requirement for XS on Solaris), which make the scripts less \nrobust.\n\nCiao,\nDscho\n"},{"id":"22564","messageId":"20060625152157.GG21864@pasky.or.cz","threadId":"4641","inReplyTo":"7vac82q6mb.fsf@assigned-by-dhcp.cox.net","subject":"Re: [PATCH] Git.pm build: Fix quoting and missing GIT-CFLAGS dependency","fromName":"Petr Baudis","fromEmail":"pasky@suse.cz","sentAt":"2006-06-25T15:21:57Z","receivedAt":"2006-06-25T15:21:57Z","isPatch":true,"sender":{"key":"pasky@ucw.cz","avatar":"https://avatars.githubusercontent.com/u/18439?v=4"},"body":"Dear diary, on Sun, Jun 25, 2006 at 05:03:24AM CEST, I got a letter\nwhere Junio C Hamano said that...\n> During our a handful piecemeal patch exchange back-and-forth on\n> the list, most of the patches did not apply mechanically, so I\n> rolled them up and have pushed out the result in \"pu\" and it\n> will mirror out shortly. I am reasonably sure it is in much\n> better shape than 24 hours ago; could you double check the\n> result for me please?\n\nIt looks good; I don't like the makefile changes a lot but more on that\nbelow.\n\nCould you please also throw in these two?\n\n[PATCH 3/7] Git.pm: Swap hash_object() parameters\n[PATCH 4/7] Git.pm: Fix Git->repository(\"/somewhere/totally/elsewhere\")\n\n..snip..\n> - RPM target -- we probably acquired a new build-dependency in\n> which case the .spec file needs to be updated;\n..snip..\n> I think we have cleared SITELIBARCH, and Git.xs building is in\n> testable state for wider audience. The remaining hurdles are to\n> make sure the RPM target is still sensible, and fix the test\n> scheme.\n> \n> Now, I am clueless about RPM, so help is very much appreciated.\n\nChris, could you help, please? Do we need to insert anything special\nto builddeps if we build own Perl module?\n\n> About the testsuite, I think with the way git-fmt-merge-msg (and\n> other Perl scripts that will use Git.pm) is munged on the\n> initial line \"#!/usr/bin/perl -I$(installedpath)\", the test\n> scheme is seriously broken. To see how yourself, have a good\n> working version of Git.pm and friends in the path your\n> git-fmt-merge-msg's first line points at, apply the following\n> patch to perl/Git.pm in your source tree and run \"make test\".\n> It will pass t5700-clone-reference.sh test, which does \"git\n> pull\" (and uses git-fmt-merge-msg) without problems X-<.\n\nYes, -I is very broken. I have abandoned it in:\n\n\tSubject: Re: [PATCH 01/12] Introduce Git.pm (v4)\n\tDate: Sat, 24 Jun 2006 13:52:27 +0200\n\nThe advantage to your approach is that it works properly without\nrequiring to make install even outside of the testsuite.\n\n> The additional dependency to perl/Makefile is needed regardless\n> of this tentative fix -- you cannot run make -C perl before\n> building perl/Makefile.\n\nYes, that bit shall be Acked-by: Petr Baudis \n\n-- \n\t\t\t\tPetr \"Pasky\" Baudis\nStuff: http://pasky.or.cz/\nA person is just about as big as the things that make them angry.\n"},{"id":"22578","messageId":"86veqp8456.fsf@blue.stonehenge.com","threadId":"4641","inReplyTo":"Pine.LNX.4.63.0606251537450.29667@wbgn013.biozentrum.uni-wuerzburg.de","subject":"Re: PPC SHA-1 Updates in \"pu\"","fromName":"Randal L. Schwartz","fromEmail":"merlyn@stonehenge.com","sentAt":"2006-06-25T18:46:29Z","receivedAt":"2006-06-25T18:46:29Z","isPatch":false,"sender":{"key":"merlyn@stonehenge.com","avatar":"https://gravatar.com/avatar/dc528d210743ff0333e6213f9ee7b33b23f1b7bc1f3c5a8c2d819074ecd7ab19?d=mp&s=160"},"body":">>>>> \"Johannes\" == Johannes Schindelin writes:\n\nJohannes> Perl, Python and sometimes even bash are good for fast\nJohannes> prototyping. But for serious work, such as profiling, they are not\nJohannes> that good.\n\nAllow my to register my strong disagreement to that statement, but then I'll\ncrawl back in my hole.\n\n-- \nRandal L. Schwartz - Stonehenge Consulting Services, Inc. - +1 503 777 0095\n \nPerl/Unix/security consulting, Technical writing, Comedy, etc. etc.\nSee PerlTraining.Stonehenge.com for onsite and open-enrollment Perl training!\n"},{"id":"22580","messageId":"Pine.LNX.4.63.0606260121040.29667@wbgn013.biozentrum.uni-wuerzburg.de","threadId":"4641","inReplyTo":"86veqp8456.fsf@blue.stonehenge.com","subject":"Re: PPC SHA-1 Updates in \"pu\"","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2006-06-25T23:23:21Z","receivedAt":"2006-06-25T23:23:21Z","isPatch":false,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi,\n\nOn Sun, 25 Jun 2006, Randal L. Schwartz wrote:\n\n> >>>>> \"Johannes\" == Johannes Schindelin writes:\n> \n> Johannes> Perl, Python and sometimes even bash are good for fast\n> Johannes> prototyping. But for serious work, such as profiling, they are not\n> Johannes> that good.\n> \n> Allow my to register my strong disagreement to that statement, but then I'll\n> crawl back in my hole.\n\nWhich statement do you mean? The \"good for fast prototyping\" one? ;-)\n\nBeing our friendly local Perl wizard, who could code cvsserver as a Perl \none-liner, you probably want to say that profiling Perl is easy. Can you \nenlighten me how to do memory _and_ timing profiling on, say, a per-line \nbasis?\n\nCiao,\nDscho\n"},{"id":"22586","messageId":"20060626015144.GA6706@coredump.intra.peff.net","threadId":"4641","inReplyTo":"Pine.LNX.4.63.0606260121040.29667@wbgn013.biozentrum.uni-wuerzburg.de","subject":"perl profiling (was: PPC SHA-1 Updates in \"pu\")","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2006-06-26T01:51:44Z","receivedAt":"2006-06-26T01:51:44Z","isPatch":false,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Mon, Jun 26, 2006 at 01:23:21AM +0200, Johannes Schindelin wrote:\n\n> one-liner, you probably want to say that profiling Perl is easy. Can you \n> enlighten me how to do memory _and_ timing profiling on, say, a per-line \n> basis?\n\nFor the timing, have you tried using Devel::SmallProf?\n perl -d:SmallProf foo.pl\n\n-Peff\n"},{"id":"22587","messageId":"7vk674mmyo.fsf@assigned-by-dhcp.cox.net","threadId":"4641","inReplyTo":"20060625152157.GG21864@pasky.or.cz","subject":"Re: [PATCH] Git.pm build: Fix quoting and missing GIT-CFLAGS dependency","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2006-06-26T06:48:31Z","receivedAt":"2006-06-26T06:48:31Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Petr Baudis writes:\n\n> Could you please also throw in these two?\n>\n> [PATCH 3/7] Git.pm: Swap hash_object() parameters\n> [PATCH 4/7] Git.pm: Fix Git->repository(\"/somewhere/totally/elsewhere\")\n\nWill take a look.\n\n> Yes, -I is very broken. I have abandoned it in:\n>\n> \tSubject: Re: [PATCH 01/12] Introduce Git.pm (v4)\n> \tDate: Sat, 24 Jun 2006 13:52:27 +0200\n>\n> The advantage to your approach is that it works properly without\n> requiring to make install even outside of the testsuite.\n\nI remember myself getting utterly discusted when I saw the\ninclusion of the build-time blib directory in the search path in\nsome other Perl code outside git.\n\nWorse yet, I suspect the order you do the two directories is\nwrong to prefer the freshly built one over the one you installed\nthe last time, but I was trying not to stare at too much for\nhealth reasons so ... ;-).\n"},{"id":"22588","messageId":"7vbqsgmmxq.fsf@assigned-by-dhcp.cox.net","threadId":"4641","inReplyTo":"Pine.LNX.4.63.0606251537450.29667@wbgn013.biozentrum.uni-wuerzburg.de","subject":"Re: PPC SHA-1 Updates in \"pu\"","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2006-06-26T06:49:05Z","receivedAt":"2006-06-26T06:49:05Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Johannes Schindelin writes:\n\n> I can live with it. Although I still think that it would be a good idea to \n> convert (at least the most commonly used) scripts to C.\n>\n> Perl, Python and sometimes even bash are good for fast prototyping. But \n> for serious work, such as profiling, they are not that good.\n\nI expect the eventual primary customer of Git.xs to be gitweb.\n\nI do not necessarily agree with what you just said about\nscripting languages. Shell is a very good implementation\nlanguage for certain serious things that does not require\nperformance and non command line UI.\n\n> And you can see different behaviour on different platforms (plus things \n> like the SunCC requirement for XS on Solaris), which make the scripts less \n> robust.\n\nI am not sure about \"less robust\" part, but it certainly\ninvolves initial pain to deal with portability across platforms.\n\nThat's why I want to make sure that the basics is sound before\nwe spend too much time and attention on converting existing\nscripts. I think the major part of bringing Git.xs series\nacceptably mergeable is not about XS programming and Perl script\nconversion, but primarily about the work on the build\ninfrastructure (Makefile, test scripts and .spec).\n"},{"id":"22873","messageId":"7vmzbvmny4.fsf_-_@assigned-by-dhcp.cox.net","threadId":"4641","inReplyTo":"7vhd2atid1.fsf@assigned-by-dhcp.cox.net","subject":"GIt.xs merge status","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2006-06-30T01:28:35Z","receivedAt":"2006-06-30T01:28:35Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Junio C Hamano writes:\n\n> Pasky, can we first iron out kinks in the build procedure and\n> installation before converting existing programs further? The\n> things I worry about currently are:\n>\n> - the SITELIBARCH gotcha I sent you a message about (and you\n> responded to it already -- was that an Acked-by?);\n\nI think this finally was cleared thanks to Pavel Roskin (and an\nunrelated workaround at the tip of \"pu\" by me).\n\n> - RPM target -- we probably acquired a new build-dependency in\n> which case the .spec file needs to be updated;\n\nI am having trouble with this. I'd appreciate help from RPM\nsavvy people (the build failure log at the end).\n\n> - Make sure Git.xs builds and installed result works fine on\n> all platforms we care about, including Cygwin and other\n> non-Linux boxes.\n\nHelp wanted from the list here. One thing to note is that I\nunderstand Pasky is working on not using Devel::PPPort to make\nthe code work with 5.6, so if your build dies with problems in\nthat area you might want to wait until that is fixed.\n\n> I'd even suggest we revert the changes to git-fmt-merge-msg to\n> keep it working for now, until the above worries are resolved.\n> Otherwise we cannot have it in \"next\" safely (and I REALLY _do_\n> want to have Git.pm infrastructure in \"next\" soonish).\n\nI am still undecided about the reverting, since in the places I\npersonally care about the program works ;-).\n\nI test-built the tip of \"pu\" 57628f0e; the RPM build log ends\nlike this:\n\nRequires(rpmlib): rpmlib(CompressedFileNames) <= 3.0.4-1 rpmlib(PayloadFilesHavePrefix) <= 4.0-1\nRequires: /bin/sh git-core = 1.4.1.rc2.g5762-1 tk >= 8.4\nProcessing files: git-debuginfo-1.4.1.rc2.g5762-1\nProvides: Git.so.debug()(64bit)\nRequires(rpmlib): rpmlib(CompressedFileNames) <= 3.0.4-1 rpmlib(PayloadFilesHavePrefix) <= 4.0-1\nChecking for unpackaged file(s): /usr/lib/rpm/check-files /var/tmp/git-1.4.1.rc2.g5762-1-root-junio\nerror: Installed (but unpackaged) file(s) found:\n /usr/lib64/perl5/5.8.6/x86_64-linux-thread-multi/perllocal.pod\n /usr/lib64/perl5/site_perl/5.8.6/x86_64-linux-thread-multi/Error.pm\n /usr/lib64/perl5/site_perl/5.8.6/x86_64-linux-thread-multi/Git.pm\n /usr/lib64/perl5/site_perl/5.8.6/x86_64-linux-thread-multi/auto/Git/.packlist\n /usr/lib64/perl5/site_perl/5.8.6/x86_64-linux-thread-multi/auto/Git/Git.bs\n /usr/lib64/perl5/site_perl/5.8.6/x86_64-linux-thread-multi/auto/Git/Git.so\n\n\nRPM build errors:\n Installed (but unpackaged) file(s) found:\n /usr/lib64/perl5/5.8.6/x86_64-linux-thread-multi/perllocal.pod\n /usr/lib64/perl5/site_perl/5.8.6/x86_64-linux-thread-multi/Error.pm\n /usr/lib64/perl5/site_perl/5.8.6/x86_64-linux-thread-multi/Git.pm\n /usr/lib64/perl5/site_perl/5.8.6/x86_64-linux-thread-multi/auto/Git/.packlist\n /usr/lib64/perl5/site_perl/5.8.6/x86_64-linux-thread-multi/auto/Git/Git.bs\n /usr/lib64/perl5/site_perl/5.8.6/x86_64-linux-thread-multi/auto/Git/Git.so\nmake: *** [rpm] Error 1\n"},{"id":"22885","messageId":"1151644101.10496.22.camel@dv","threadId":"4641","inReplyTo":"7vmzbvmny4.fsf_-_@assigned-by-dhcp.cox.net","subject":"Re: GIt.xs merge status","fromName":"Pavel Roskin","fromEmail":"proski@gnu.org","sentAt":"2006-06-30T05:08:21Z","receivedAt":"2006-06-30T05:08:21Z","isPatch":false,"sender":{"key":"proski@gnu.org","avatar":null},"body":"On Thu, 2006-06-29 at 18:28 -0700, Junio C Hamano wrote:\n> Checking for unpackaged file(s): /usr/lib/rpm/check-files /var/tmp/git-1.4.1.rc2.g5762-1-root-junio\n> error: Installed (but unpackaged) file(s) found:\n> /usr/lib64/perl5/5.8.6/x86_64-linux-thread-multi/perllocal.pod\n> /usr/lib64/perl5/site_perl/5.8.6/x86_64-linux-thread-multi/Error.pm\n> /usr/lib64/perl5/site_perl/5.8.6/x86_64-linux-thread-multi/Git.pm\n> /usr/lib64/perl5/site_perl/5.8.6/x86_64-linux-thread-multi/auto/Git/.packlist\n> /usr/lib64/perl5/site_perl/5.8.6/x86_64-linux-thread-multi/auto/Git/Git.bs\n> /usr/lib64/perl5/site_perl/5.8.6/x86_64-linux-thread-multi/auto/Git/Git.so\n\nI guess all this perl stuff should be in a separate module perl-Git to\ncomply with Red Hat conventions. This would make git-core depend on\nperl-Git, but it's OK.\n\nError.pm is already provided by perl-Error. If we require perl(Error)\nfor building, it won't be installed. Actually, probing for Error.pm is\nincorrect, so I'm fixing it.\n\nGit.bs, .packlist and perllocal.pod should be removed - that's what\nother Perl packages do. Red Hat packages use INSTALLDIRS=vendor so that\n\"site_perl\" becomes \"vendor_perl\".\n\nWhile hacking that, I have wound that \"--without doc\" is broken in pu,\nso I'm fixing it as well. The patches will be sent shortly.\n\n-- \nRegards,\nPavel Roskin\n"},{"id":"22892","messageId":"7vlkrfkt6q.fsf_-_@assigned-by-dhcp.cox.net","threadId":"4641","inReplyTo":"1151644101.10496.22.camel@dv","subject":"Re: Git.xs merge status","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2006-06-30T07:18:21Z","receivedAt":"2006-06-30T07:18:21Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Pavel Roskin writes:\n\n> I guess all this perl stuff should be in a separate module perl-Git to\n> comply with Red Hat conventions. This would make git-core depend on\n> perl-Git, but it's OK.\n>\n> Error.pm is already provided by perl-Error. If we require perl(Error)\n> for building, it won't be installed. Actually, probing for Error.pm is\n> incorrect, so I'm fixing it.\n>\n> Git.bs, .packlist and perllocal.pod should be removed - that's what\n> other Perl packages do. Red Hat packages use INSTALLDIRS=vendor so that\n> \"site_perl\" becomes \"vendor_perl\".\n>\n> While hacking that, I have wound that \"--without doc\" is broken in pu,\n> so I'm fixing it as well. The patches will be sent shortly.\n\nThanks.\n\nThe kernel.org machine I am using for testing does not seem to\nhave perl-Error installed, and I suspect Pasky arranged to ship\nour own Error.pm for people building git from source because the\npackage is not so widely installed. I guess I should ask the\nadmins there before I can build perl-Git RPMs for release. \n\nI am doing this preparation not for the upcoming 1.4.1 but later\nthan that -- perhaps way later than that -- so there is no rush.\n"},{"id":"22895","messageId":"20060630032812.zg9vgkksg08kkkk4@webmail.spamcop.net","threadId":"4641","inReplyTo":"7vlkrfkt6q.fsf_-_@assigned-by-dhcp.cox.net","subject":"Re: Git.xs merge status","fromName":"Pavel Roskin","fromEmail":"proski@gnu.org","sentAt":"2006-06-30T07:28:12Z","receivedAt":"2006-06-30T07:28:12Z","isPatch":false,"sender":{"key":"proski@gnu.org","avatar":null},"body":"Quoting Junio C Hamano :\n\n> The kernel.org machine I am using for testing does not seem to\n> have perl-Error installed, and I suspect Pasky arranged to ship\n> our own Error.pm for people building git from source because the\n> package is not so widely installed. I guess I should ask the\n> admins there before I can build perl-Git RPMs for release.\n\nIt's better than to have conflicting packages (perl-Git and perl-Error). The\nbuild requirement can be relaxed if needed (either by finding and removing\nError* after the install or by adding another flag to Makefile.PL), but I think\nit's logical to have it because perl-Error would be needed by git-core anyway.\n\nAnother solution would be to arrange Error.pm to be installed and used as\nGit::Error, but that would be a case of code duplication.\n\n--\nRegards,\nPavel Roskin\n"},{"id":"22904","messageId":"Pine.LNX.4.63.0606301150250.29667@wbgn013.biozentrum.uni-wuerzburg.de","threadId":"4641","inReplyTo":"7vmzbvmny4.fsf_-_@assigned-by-dhcp.cox.net","subject":"Re: GIt.xs merge status","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2006-06-30T09:53:53Z","receivedAt":"2006-06-30T09:53:53Z","isPatch":false,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi,\n\nOn Thu, 29 Jun 2006, Junio C Hamano wrote:\n\n> Junio C Hamano writes:\n> \n> > - Make sure Git.xs builds and installed result works fine on\n> > all platforms we care about, including Cygwin and other\n> > non-Linux boxes.\n> \n> Help wanted from the list here. One thing to note is that I\n> understand Pasky is working on not using Devel::PPPort to make\n> the code work with 5.6, so if your build dies with problems in\n> that area you might want to wait until that is fixed.\n\nI'll try it (it's in pu, right?). Note that breaking git-fmt-merge-msg \nmight be a good way to force somebody to rewrite it in C ;-)\n\nNote that on my iBook (where I reported the Devel::PPPort problem), I _do_ \nhave perl modules compiled from source, using SWIG. So, there _should_ be \nno problem to get it to run (although I have problems with my eyes ever \nsince I looked into the code generated by SWIG).\n\nCiao,\nDscho\n"},{"id":"22909","messageId":"7vodwbj5wf.fsf@assigned-by-dhcp.cox.net","threadId":"4641","inReplyTo":"Pine.LNX.4.63.0606301150250.29667@wbgn013.biozentrum.uni-wuerzburg.de","subject":"Re: GIt.xs merge status","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2006-06-30T10:26:40Z","receivedAt":"2006-06-30T10:26:40Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Johannes Schindelin writes:\n\n> I'll try it (it's in pu, right?). Note that breaking git-fmt-merge-msg \n> might be a good way to force somebody to rewrite it in C ;-)\n\nIt would hopefully not come to that (and that is I am playing\nsafe and keeping the series in \"pu\"), and even if it did, I am\nhoping that Perl is so ubiquitous that people would fix it up\nquickly.\n"},{"id":"23013","messageId":"20060701235906.GE29115@pasky.or.cz","threadId":"4641","inReplyTo":"7vk674mmyo.fsf@assigned-by-dhcp.cox.net","subject":"[POOL] Who likes running Git without make install?","fromName":"Petr Baudis","fromEmail":"pasky@suse.cz","sentAt":"2006-07-01T23:59:06Z","receivedAt":"2006-07-01T23:59:06Z","isPatch":false,"sender":{"key":"pasky@ucw.cz","avatar":"https://avatars.githubusercontent.com/u/18439?v=4"},"body":"Dear diary, on Mon, Jun 26, 2006 at 08:48:31AM CEST, I got a letter\nwhere Junio C Hamano said that...\n> I remember myself getting utterly discusted when I saw the\n> inclusion of the build-time blib directory in the search path in\n> some other Perl code outside git.\n\nWell, yes, it is ugly, but it was really cool that we could have used\nGit without installing it anywhere.\n\nBut perhaps that's just me refusing to break his old ways of doing\nthings. Does anyone else care about it? (And why?)\n\n> Worse yet, I suspect the order you do the two directories is\n> wrong to prefer the freshly built one over the one you installed\n> the last time, but I was trying not to stare at too much for\n> health reasons so ... ;-).\n\nOh man, of course you are right. :-)\n\n-- \n\t\t\t\tPetr \"Pasky\" Baudis\nStuff: http://pasky.or.cz/\nSnow falling on Perl. White noise covering line noise.\nHides all the bugs too. -- J. Putnam\n"},{"id":"23015","messageId":"7vlkrcdg6d.fsf@assigned-by-dhcp.cox.net","threadId":"4641","inReplyTo":"20060701235906.GE29115@pasky.or.cz","subject":"Re: [POOL] Who likes running Git without make install?","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2006-07-02T00:05:46Z","receivedAt":"2006-07-02T00:05:46Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Petr Baudis writes:\n\n> Dear diary, on Mon, Jun 26, 2006 at 08:48:31AM CEST, I got a letter\n> where Junio C Hamano said that...\n>> I remember myself getting utterly discusted when I saw the\n>> inclusion of the build-time blib directory in the search path in\n>> some other Perl code outside git.\n>\n> Well, yes, it is ugly, but it was really cool that we could have used\n> Git without installing it anywhere.\n>\n> But perhaps that's just me refusing to break his old ways of doing\n> things. Does anyone else care about it? (And why?)\n>\n>> Worse yet, I suspect the order you do the two directories is\n>> wrong to prefer the freshly built one over the one you installed\n>> the last time, but I was trying not to stare at too much for\n>> health reasons so ... ;-).\n>\n> Oh man, of course you are right. :-)\n\nThat's fixed in ancient past in git timescale. Why are you\nbringing it up again? ;-)\n"},{"id":"23017","messageId":"7vhd20dg2g.fsf@assigned-by-dhcp.cox.net","threadId":"4641","inReplyTo":"20060701235906.GE29115@pasky.or.cz","subject":"Re: [POOL] Who likes running Git without make install?","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2006-07-02T00:08:07Z","receivedAt":"2006-07-02T00:08:07Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Petr Baudis writes:\n\n> Dear diary, on Mon, Jun 26, 2006 at 08:48:31AM CEST, I got a letter\n> where Junio C Hamano said that...\n>> I remember myself getting utterly discusted when I saw the\n>> inclusion of the build-time blib directory in the search path in\n>> some other Perl code outside git.\n>\n> Well, yes, it is ugly, but it was really cool that we could have used\n> Git without installing it anywhere.\n>\n> But perhaps that's just me refusing to break his old ways of doing\n> things. Does anyone else care about it? (And why?)\n\nWell, for a quick test to see if I haven't broken anything, I\nuse a new shell and do \". ./+denv\" in my git repository where\nthat file has something like this:\n\n $ cat ./+denv\n :\n\n GIT_EXEC_PATH=`pwd`\n PATH=`pwd`:/usr/bin:/bin\n\n export GIT_EXEC_PATH PATH\n\nSo to a certain degree, yes I do care.\n"},{"id":"23031","messageId":"20060702113057.GF29115@pasky.or.cz","threadId":"4641","inReplyTo":"7vhd20dg2g.fsf@assigned-by-dhcp.cox.net","subject":"Re: [POOL] Who likes running Git without make install?","fromName":"Petr Baudis","fromEmail":"pasky@suse.cz","sentAt":"2006-07-02T11:30:57Z","receivedAt":"2006-07-02T11:30:57Z","isPatch":false,"sender":{"key":"pasky@ucw.cz","avatar":"https://avatars.githubusercontent.com/u/18439?v=4"},"body":"Dear diary, on Sun, Jul 02, 2006 at 02:05:46AM CEST, I got a letter\nwhere Junio C Hamano said that...\n> That's fixed in ancient past in git timescale. Why are you\n> bringing it up again? ;-)\n\nBecause, it is, well, not fixed? ;-) (Apparently.)\n\nDear diary, on Sun, Jul 02, 2006 at 02:08:07AM CEST, I got a letter\nwhere Junio C Hamano said that...\n> Petr Baudis writes:\n> \n> > Dear diary, on Mon, Jun 26, 2006 at 08:48:31AM CEST, I got a letter\n> > where Junio C Hamano said that...\n> >> I remember myself getting utterly discusted when I saw the\n> >> inclusion of the build-time blib directory in the search path in\n> >> some other Perl code outside git.\n> >\n> > Well, yes, it is ugly, but it was really cool that we could have used\n> > Git without installing it anywhere.\n> >\n> > But perhaps that's just me refusing to break his old ways of doing\n> > things. Does anyone else care about it? (And why?)\n> \n> Well, for a quick test to see if I haven't broken anything, I\n> use a new shell and do \". ./+denv\" in my git repository where\n> that file has something like this:\n> \n> $ cat ./+denv\n> :\n> \n> GIT_EXEC_PATH=`pwd`\n> PATH=`pwd`:/usr/bin:/bin\n> \n> export GIT_EXEC_PATH PATH\n> \n> So to a certain degree, yes I do care.\n\nBut it is currently broken:\n\nxpasky@machine[0:0]~/git-pb$ rm -rf /home/xpasky/lib/perl5/\nxpasky@machine[0:0]~/git-pb$ ./git-mv\nCan't locate Git.pm in @INC (...)\n\n(And I can't see any change that could aim to fix it.)\n\n-- \n\t\t\t\tPetr \"Pasky\" Baudis\nStuff: http://pasky.or.cz/\nSnow falling on Perl. White noise covering line noise.\nHides all the bugs too. -- J. Putnam\n"},{"id":"23037","messageId":"7virmf6i1q.fsf@assigned-by-dhcp.cox.net","threadId":"4641","inReplyTo":"20060702113057.GF29115@pasky.or.cz","subject":"Re: [POOL] Who likes running Git without make install?","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2006-07-02T17:19:29Z","receivedAt":"2006-07-02T17:19:29Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Petr Baudis writes:\n\n> Dear diary, on Sun, Jul 02, 2006 at 02:05:46AM CEST, I got a letter\n> where Junio C Hamano said that...\n>> That's fixed in ancient past in git timescale. Why are you\n>> bringing it up again? ;-)\n>\n> Because, it is, well, not fixed? ;-) (Apparently.)\n\nThat response is about \"Worse yet, the order is wrong -- ah you\nare right\" exchange, not about in-place execution.\n\n>> Well, for a quick test to see if I haven't broken anything, I\n>> use a new shell and do \". ./+denv\" in my git repository where\n>> that file has something like this:\n>> \n>> $ cat ./+denv\n>> :\n>> \n>> GIT_EXEC_PATH=`pwd`\n>> PATH=`pwd`:/usr/bin:/bin\n>> \n>> export GIT_EXEC_PATH PATH\n>> \n>> So to a certain degree, yes I do care.\n>\n> But it is currently broken:\n\nI know. The scriptlet needs to muck with PERL5LIB too.\n"},{"id":"23087","messageId":"7vslljrxe0.fsf_-_@assigned-by-dhcp.cox.net","threadId":"4641","inReplyTo":"20060701235906.GE29115@pasky.or.cz","subject":"Re: [POLL] Who likes running Git without make install?","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2006-07-03T06:54:47Z","receivedAt":"2006-07-03T06:54:47Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Petr Baudis writes:\n\n> Well, yes, it is ugly, but it was really cool that we could have used\n> Git without installing it anywhere.\n>\n> But perhaps that's just me refusing to break his old ways of doing\n> things. Does anyone else care about it? (And why?)\n\nI do not think you need to break your old ways. Perhaps a patch\nlike this might help.\n\n-- >8 --\nINSTALL: a tip for running after building but without installing.\n\nSigned-off-by: Junio C Hamano \n---\ndiff --git a/INSTALL b/INSTALL\nindex f8337e2..ed502de 100644\n--- a/INSTALL\n+++ b/INSTALL\n@@ -29,6 +29,19 @@ Issues of note:\n has been actively developed since 1997, and people have moved over to\n graphical file managers.\n \n+ - You can use git after building but without installing if you\n+ wanted to. Various git commands need to find other git\n+ commands and scripts to do their work, so you would need to\n+ arrange a few environment variables to tell them that their\n+ friends will be found in your built source area instead of at\n+ their standard installation area. Something like this works\n+ for me:\n+\n+\tGIT_EXEC_PATH=`pwd`\n+\tPATH=`pwd`:$PATH\n+\tPERL5LIB=`pwd`/perl/blib/lib:`pwd`/perl/blib/arch/auto/Git\n+\texport GIT_EXEC_PATH PATH PERL5LIB\n+\n - Git is reasonably self-sufficient, but does depend on a few external\n programs and libraries:\n \n"},{"id":"23089","messageId":"20060703075850.GL29115@pasky.or.cz","threadId":"4641","inReplyTo":"7vslljrxe0.fsf_-_@assigned-by-dhcp.cox.net","subject":"Re: [POLL] Who likes running Git without make install?","fromName":"Petr Baudis","fromEmail":"pasky@suse.cz","sentAt":"2006-07-03T07:58:50Z","receivedAt":"2006-07-03T07:58:50Z","isPatch":false,"sender":{"key":"pasky@ucw.cz","avatar":"https://avatars.githubusercontent.com/u/18439?v=4"},"body":"Dear diary, on Mon, Jul 03, 2006 at 08:54:47AM CEST, I got a letter\nwhere Junio C Hamano said that...\n> -- >8 --\n> INSTALL: a tip for running after building but without installing.\n> \n> Signed-off-by: Junio C Hamano \n\nAcked-by: Petr Baudis \n\nI can live with this \"weak (D3)\". 99% of Git users probably use\ninstalled Git instance anyway and most of the rest are likely to be Git\ndevelopers testing new code who can do this extra environment setup.\n\n-- \n\t\t\t\tPetr \"Pasky\" Baudis\nStuff: http://pasky.or.cz/\nSnow falling on Perl. White noise covering line noise.\nHides all the bugs too. -- J. Putnam\n"},{"id":"23091","messageId":"7vmzbrrtz4.fsf@assigned-by-dhcp.cox.net","threadId":"4641","inReplyTo":"20060703075850.GL29115@pasky.or.cz","subject":"Re: [POLL] Who likes running Git without make install?","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2006-07-03T08:08:31Z","receivedAt":"2006-07-03T08:08:31Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Petr Baudis writes:\n\n> Dear diary, on Mon, Jul 03, 2006 at 08:54:47AM CEST, I got a letter\n> where Junio C Hamano said that...\n>> -- >8 --\n>> INSTALL: a tip for running after building but without installing.\n>> \n>> Signed-off-by: Junio C Hamano \n>\n> Acked-by: Petr Baudis \n>\n> I can live with this \"weak (D3)\". 99% of Git users probably use\n> installed Git instance anyway and most of the rest are likely to be Git\n> developers testing new code who can do this extra environment setup.\n\nYou earlier had to set two environment variables anyway but you\nhave added another. I do not see what's weak about it.\n"},{"id":"23093","messageId":"20060703081725.GM29115@pasky.or.cz","threadId":"4641","inReplyTo":"7vmzbrrtz4.fsf@assigned-by-dhcp.cox.net","subject":"Re: [POLL] Who likes running Git without make install?","fromName":"Petr Baudis","fromEmail":"pasky@suse.cz","sentAt":"2006-07-03T08:17:25Z","receivedAt":"2006-07-03T08:17:25Z","isPatch":false,"sender":{"key":"pasky@ucw.cz","avatar":"https://avatars.githubusercontent.com/u/18439?v=4"},"body":"Dear diary, on Mon, Jul 03, 2006 at 10:08:31AM CEST, I got a letter\nwhere Junio C Hamano said that...\n> Petr Baudis writes:\n> \n> > Dear diary, on Mon, Jul 03, 2006 at 08:54:47AM CEST, I got a letter\n> > where Junio C Hamano said that...\n> >> -- >8 --\n> >> INSTALL: a tip for running after building but without installing.\n> >> \n> >> Signed-off-by: Junio C Hamano \n> >\n> > Acked-by: Petr Baudis \n> >\n> > I can live with this \"weak (D3)\". 99% of Git users probably use\n> > installed Git instance anyway and most of the rest are likely to be Git\n> > developers testing new code who can do this extra environment setup.\n> \n> You earlier had to set two environment variables anyway but you\n> have added another. I do not see what's weak about it.\n\nI don't usually use the git wrapper so I got away without setting\nGIT_EXEC_PATH yet. ;-)\n\n-- \n\t\t\t\tPetr \"Pasky\" Baudis\nStuff: http://pasky.or.cz/\nSnow falling on Perl. White noise covering line noise.\nHides all the bugs too. -- J. Putnam\n"},{"id":"23094","messageId":"Pine.LNX.4.63.0607031037100.29667@wbgn013.biozentrum.uni-wuerzburg.de","threadId":"4641","inReplyTo":"20060703081725.GM29115@pasky.or.cz","subject":"Re: [POLL] Who likes running Git without make install?","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2006-07-03T08:37:44Z","receivedAt":"2006-07-03T08:37:44Z","isPatch":false,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi,\n\nOn Mon, 3 Jul 2006, Petr Baudis wrote:\n\n> Dear diary, on Mon, Jul 03, 2006 at 10:08:31AM CEST, I got a letter\n> where Junio C Hamano said that...\n> > Petr Baudis writes:\n> > \n> > > Dear diary, on Mon, Jul 03, 2006 at 08:54:47AM CEST, I got a letter\n> > > where Junio C Hamano said that...\n> > >> -- >8 --\n> > >> INSTALL: a tip for running after building but without installing.\n> > >> \n> > >> Signed-off-by: Junio C Hamano \n> > >\n> > > Acked-by: Petr Baudis \n> > >\n> > > I can live with this \"weak (D3)\". 99% of Git users probably use\n> > > installed Git instance anyway and most of the rest are likely to be Git\n> > > developers testing new code who can do this extra environment setup.\n> > \n> > You earlier had to set two environment variables anyway but you\n> > have added another. I do not see what's weak about it.\n> \n> I don't usually use the git wrapper so I got away without setting\n> GIT_EXEC_PATH yet. ;-)\n\nThis is the config.mak I use everywhere:\n\n-- snip --\nbindir = $(shell pwd)\ntemplate_dir = $(bindir)/templates/blt\nGIT_PYTHON_DIR = $(bindir)/compat\n-- snap --\n\nNo environment variable.\n\nCiao,\nDscho\n"}]}