x86 asm SHA1 (draft)

x86 asm SHA1 (draft)

[linux]

As long as I was hacking on PowerPC asm, I figured I might as well take
a crack at the openssl dependency, too.  This is a draft x86 SHA1 that
is a little over 2x faster than the C version on a Pentium M.  I haven't
yet started competing with the OpenSSL code.

This might be useful for the folks who are careful about licensing and
don't like to get mixed up in the OpenSSL/GPL license tangle.

Work in progress, but it functions.  Public domain.


--- /dev/null	2006-04-13 05:29:14.000000000 -0400
+++ sha1x86.S	2006-06-23 09:14:21.000000000 -0400
@@ -0,0 +1,233 @@
+	.text
+#define K1 0x5a827999
+#define K2 0x6ed9eba1
+#define K3 0x8f1bbcdc
+#define K4 0xca62c1d6
+
+#define A %edi
+#define B %ebx
+#define C %ecx
+#define D %edx
+#define E %ebp
+
+#define T %eax
+
+#define MIX(base) \
+	movl	60-base(%esp),T;	\
+	xorl	52-base(%esp),T;	\
+	xorl	28-base(%esp),T;	\
+	xorl	8-base(%esp),T;		\
+	roll	$1,T
+
+/*
+ *In these choice functions, C is the value most recently modified
+ * (It was the B that was rotated in the previous round), so schedule its
+ * use as late as possible.
+ */
+
+/* Choice function: bitwise b ? c : d = ((d ^ c) & b) ^ d */
+#define F1(b,c,d,e) \
+	movl	d,T;	\
+	xorl	c,T;	\
+	andl	b,T;	\
+	roll	$30,b;	\
+	xorl	d,T;	\
+	addl	T,e
+
+/* Parity function: b ^ c ^ d = (b ^ d) ^ c */
+#define F2(b,c,d,e) \
+	movl	b,T;	\
+	roll	$30,b;	\
+	xorl	d,T;	\
+	xorl	c,T;	\
+	addl	T,e
+
+/* Majority function: (b&c) | (c&d) | (d&b) = (b&d) + ((b^d)&c) */
+#define F3(b,c,d,e) \
+	movl	b,T;	\
+	andl	d,T;	\
+	addl	T,e;	\
+	movl	b,T;	\
+	roll	$30,b;	\
+	xorl	d,T;	\
+	andl	c,T;	\
+	addl	T,e
+
+/*
+ * Register assignments:
+ * %eax - temp
+ * %esi - Pointer to input data
+ * %edi, %ebx, %ecx, %edx, %ebp - A..E
+ */
+
+ /*
+  * The basic round:
+  * e += ROTL(e,5) + F(b,c,d) + W[i] + 0x5a827999
+  */
+
+/* This version fetches (and swaps) data from %esi */
+#define ROUND_LOAD(F,a,b,c,d,e,K) \
+	lodsl;		\
+	addl	$K,e;	\
+	bswap	T;	\
+	addl	T,e;	\
+	pushl	T;	\
+	F(b,c,d,e);	\
+	movl	a,T;	\
+	roll	$5,T;	\
+	addl	T,e
+
+/* The standard round: compute the new W value and push it on the stack */
+#define ROUND_MIX(F,a,b,c,d,e,K) \
+	MIX(0);		\
+	addl	$K,e;	\
+	addl	T,e;	\
+	pushl	T;	\
+	F(b,c,d,e);	\
+	movl	a,T;	\
+	roll	$5,T;	\
+	addl	T,e
+
+/* Mix the W[] value, but do NOT push it, as it's never used */
+#define ROUND_LAST(F,a,b,c,d,e,K,base) \
+	MIX(base);	\
+	addl	$K,e;	\
+	addl	T,e;	\
+	F(b,c,d,e);	\
+	movl	a,T;	\
+	roll	$5,T;	\
+	addl	T,e
+
+/* Args are context (A..E, then a W[] array), then input data */
+.globl shaHashBlock
+	.type	shaHashBlock, @function
+shaHashBlock:
+	pushl	%ebp
+	pushl	%ebx
+	pushl	%esi
+	pushl	%edi
+/* Args now start at 20(%esp) */
+
+	movl	20(%esp),T
+	movl	24(%esp),%esi
+
+	movl	  (T),A
+	movl	 4(T),B
+	movl	 8(T),C
+	movl	12(T),D
+	movl	16(T),E
+
+	ROUND_LOAD(F1, A,B,C,D,E, K1);
+	ROUND_LOAD(F1, E,A,B,C,D, K1);
+	ROUND_LOAD(F1, D,E,A,B,C, K1);
+	ROUND_LOAD(F1, C,D,E,A,B, K1);
+	ROUND_LOAD(F1, B,C,D,E,A, K1);
+
+	ROUND_LOAD(F1, A,B,C,D,E, K1);
+	ROUND_LOAD(F1, E,A,B,C,D, K1);
+	ROUND_LOAD(F1, D,E,A,B,C, K1);
+	ROUND_LOAD(F1, C,D,E,A,B, K1);
+	ROUND_LOAD(F1, B,C,D,E,A, K1);
+
+	ROUND_LOAD(F1, A,B,C,D,E, K1);
+	ROUND_LOAD(F1, E,A,B,C,D, K1);
+	ROUND_LOAD(F1, D,E,A,B,C, K1);
+	ROUND_LOAD(F1, C,D,E,A,B, K1);
+	ROUND_LOAD(F1, B,C,D,E,A, K1);
+
+	ROUND_LOAD(F1, A,B,C,D,E, K1);
+	ROUND_MIX(F1, E,A,B,C,D, K1);
+	ROUND_MIX(F1, D,E,A,B,C, K1);
+	ROUND_MIX(F1, C,D,E,A,B, K1);
+	ROUND_MIX(F1, B,C,D,E,A, K1);
+
+	ROUND_MIX(F2, A,B,C,D,E, K2);
+	ROUND_MIX(F2, E,A,B,C,D, K2);
+	ROUND_MIX(F2, D,E,A,B,C, K2);
+	ROUND_MIX(F2, C,D,E,A,B, K2);
+	ROUND_MIX(F2, B,C,D,E,A, K2);
+
+	ROUND_MIX(F2, A,B,C,D,E, K2);
+	ROUND_MIX(F2, E,A,B,C,D, K2);
+	ROUND_MIX(F2, D,E,A,B,C, K2);
+	ROUND_MIX(F2, C,D,E,A,B, K2);
+	ROUND_MIX(F2, B,C,D,E,A, K2);
+
+	ROUND_MIX(F2, A,B,C,D,E, K2);
+	ROUND_MIX(F2, E,A,B,C,D, K2);
+	ROUND_MIX(F2, D,E,A,B,C, K2);
+	ROUND_MIX(F2, C,D,E,A,B, K2);
+	ROUND_MIX(F2, B,C,D,E,A, K2);
+
+	ROUND_MIX(F2, A,B,C,D,E, K2);
+	ROUND_MIX(F2, E,A,B,C,D, K2);
+	ROUND_MIX(F2, D,E,A,B,C, K2);
+	ROUND_MIX(F2, C,D,E,A,B, K2);
+	ROUND_MIX(F2, B,C,D,E,A, K2);
+
+	ROUND_MIX(F3, A,B,C,D,E, K3);
+	ROUND_MIX(F3, E,A,B,C,D, K3);
+	ROUND_MIX(F3, D,E,A,B,C, K3);
+	ROUND_MIX(F3, C,D,E,A,B, K3);
+	ROUND_MIX(F3, B,C,D,E,A, K3);
+
+	ROUND_MIX(F3, A,B,C,D,E, K3);
+	ROUND_MIX(F3, E,A,B,C,D, K3);
+	ROUND_MIX(F3, D,E,A,B,C, K3);
+	ROUND_MIX(F3, C,D,E,A,B, K3);
+	ROUND_MIX(F3, B,C,D,E,A, K3);
+
+	ROUND_MIX(F3, A,B,C,D,E, K3);
+	ROUND_MIX(F3, E,A,B,C,D, K3);
+	ROUND_MIX(F3, D,E,A,B,C, K3);
+	ROUND_MIX(F3, C,D,E,A,B, K3);
+	ROUND_MIX(F3, B,C,D,E,A, K3);
+
+	ROUND_MIX(F3, A,B,C,D,E, K3);
+	ROUND_MIX(F3, E,A,B,C,D, K3);
+	ROUND_MIX(F3, D,E,A,B,C, K3);
+	ROUND_MIX(F3, C,D,E,A,B, K3);
+	ROUND_MIX(F3, B,C,D,E,A, K3);
+
+	ROUND_MIX(F2, A,B,C,D,E, K4);
+	ROUND_MIX(F2, E,A,B,C,D, K4);
+	ROUND_MIX(F2, D,E,A,B,C, K4);
+	ROUND_MIX(F2, C,D,E,A,B, K4);
+	ROUND_MIX(F2, B,C,D,E,A, K4);
+
+	ROUND_MIX(F2, A,B,C,D,E, K4);
+	ROUND_MIX(F2, E,A,B,C,D, K4);
+	ROUND_MIX(F2, D,E,A,B,C, K4);
+	ROUND_MIX(F2, C,D,E,A,B, K4);
+	ROUND_MIX(F2, B,C,D,E,A, K4);
+
+	ROUND_MIX(F2, A,B,C,D,E, K4);
+	ROUND_MIX(F2, E,A,B,C,D, K4);
+	ROUND_MIX(F2, D,E,A,B,C, K4);
+	ROUND_MIX(F2, C,D,E,A,B, K4);
+	ROUND_MIX(F2, B,C,D,E,A, K4);
+
+	ROUND_MIX(F2, A,B,C,D,E, K4);
+	ROUND_MIX(F2, E,A,B,C,D, K4);
+	ROUND_LAST(F2, D,E,A,B,C, K4, 0);
+	ROUND_LAST(F2, C,D,E,A,B, K4, 4);
+	ROUND_LAST(F2, B,C,D,E,A, K4, 8);
+
+	addl	$77*4,%esp
+
+	movl	20(%esp),T
+
+	addl	A,  (T)
+	addl	B, 4(T)
+	addl	C, 8(T)
+	addl	D,12(T)
+	addl	E,16(T)
+
+	popl	%edi
+	popl	%esi
+	popl	%ebx
+	popl	%ebp
+
+	ret
+
+	.size	shaHashBlock, .-shaHashBlock
--- /dev/null	2006-04-13 05:29:14.000000000 -0400
+++ sha1asm.h	2006-06-23 10:24:35.578683250 -0400
@@ -0,0 +1,12 @@
+#include <stdint.h>
+#include <stddef.h>	/* For size_t */
+
+typedef struct sha_ctx {
+  uint32_t hash[5];
+  uint32_t data[16];
+  uint32_t sizeL, sizeH;
+} SHA_CTX;
+
+void SHA1_Init(SHA_CTX *ctx);
+void SHA1_Update(SHA_CTX *ctx, const void *dataIn, size_t len);
+void SHA1_Final(unsigned char hashout[20], SHA_CTX *ctx);
--- /dev/null	2006-04-13 05:29:14.000000000 -0400
+++ sha1asm.c	2006-06-23 10:25:26.798757250 -0400
@@ -0,0 +1,163 @@
+
+#include <string.h>	/* For memcpy */
+#include <arpa/inet.h>	/* For htonl */
+
+#include "sha1asm.h"
+
+#if ASM
+extern void shaHashBlock(SHA_CTX *ctx, uint32_t const *input);
+#else
+
+/* 
+ * This chunk of this file are subject to the Mozilla Public
+ * License Version 1.1 (the "License"); you may not use this file
+ * except in compliance with the License. You may obtain a copy of
+ * the License at http://www.mozilla.org/MPL/
+ * 
+ * Software distributed under the License is distributed on an "AS
+ * IS" basis, WITHOUT WARRANTY OF ANY KIND, either express or
+ * implied. See the License for the specific language governing
+ * rights and limitations under the License.
+ * 
+ * The Original Code is SHA 180-1 Reference Implementation (Compact version)
+ * 
+ * The Initial Developer of the Original Code is Paul Kocher of
+ * Cryptography Research.  Portions created by Paul Kocher are 
+ * Copyright (C) 1995-9 by Cryptography Research, Inc.  All
+ * Rights Reserved.
+ * 
+ * Contributor(s):
+ *
+ *     Paul Kocher
+ * 
+ * Alternatively, this portion of this file may be used under the
+ * terms of the GNU General Public License Version 2 or later (the
+ * "GPL"), in which case the provisions of the GPL are applicable 
+ * instead of those above.  If you wish to allow use of your 
+ * version of this file only under the terms of the GPL and not to
+ * allow others to use your version of this file under the MPL,
+ * indicate your decision by deleting the provisions above and
+ * replace them with the notice and other provisions required by
+ * the GPL.  If you do not delete the provisions above, a recipient
+ * may use your version of this file under either the MPL or the
+ * GPL.
+ */
+
+#define ROTL(X,n) (((X) << (n)) | ((X) >> (32-(n))))
+
+static void
+shaHashBlock(SHA_CTX *ctx, uint32_t const *input)
+{
+	int i;
+	uint32_t A,B,C,D,E,T;
+	uint32_t W[80];
+
+	for (i = 0; i < 16; i++)
+		W[i] = ntohl(input[i]);
+	for (i = 16; i < 80; i++) {
+		T = W[i-3] ^ W[i-8] ^ W[i-14] ^ W[i-16];
+		W[i] = ROTL(T, 1);
+	}
+
+	A = ctx->hash[0];
+	B = ctx->hash[1];
+	C = ctx->hash[2];
+	D = ctx->hash[3];
+	E = ctx->hash[4];
+
+	for (i = 0; i < 20; i++) {
+		T = ROTL(A,5) + (((C^D)&B)^D)     + E + W[i] + 0x5a827999;
+		E = D; D = C; C = ROTL(B, 30); B = A; A = T;
+	}
+	for (i = 20; i < 40; i++) {
+		T = ROTL(A,5) + (B^C^D)           + E + W[i] + 0x6ed9eba1;
+		E = D; D = C; C = ROTL(B, 30); B = A; A = T;
+	}
+	for (i = 40; i < 60; i++) {
+		T = ROTL(A,5) + (B&C) + (D&(B^C)) + E + W[i] + 0x8f1bbcdc;
+		E = D; D = C; C = ROTL(B, 30); B = A; A = T;
+	}
+	for (i = 60; i < 80; i++) {
+		T = ROTL(A,5) + (B^C^D)           + E + W[i] + 0xca62c1d6;
+		E = D; D = C; C = ROTL(B, 30); B = A; A = T;
+	}
+
+	ctx->hash[0] += A;
+	ctx->hash[1] += B;
+	ctx->hash[2] += C;
+	ctx->hash[3] += D;
+	ctx->hash[4] += E;
+}
+#endif
+
+/*
+ * The following part of the file is NOT subject to the above license, and is
+ * instead placed in the public domain.
+ */
+
+void
+SHA1_Init(SHA_CTX *ctx)
+{
+  /* Initialize H with the magic constants (see FIPS180 for constants)
+   */
+  ctx->hash[0] = 0x67452301;
+  ctx->hash[1] = 0xefcdab89;
+  ctx->hash[2] = 0x98badcfe;
+  ctx->hash[3] = 0x10325476;
+  ctx->hash[4] = 0xc3d2e1f0;
+
+  ctx->sizeH = ctx->sizeL = 0;
+}
+
+void
+SHA1_Update(SHA_CTX *ctx, const void *data, size_t len)
+{
+	unsigned pos = ctx->sizeL % 64;
+
+	ctx->sizeL += len;
+	ctx->sizeH += (ctx->sizeL < (uint32_t)len);
+	ctx->sizeH += len >> 16 >> 16;	/* In case size_t is 64 bits */
+
+	/* Leading partial block */
+	if (pos) {
+		unsigned avail = 64 - pos;
+		if (avail > len)
+			goto end;
+		memcpy((char *)ctx->data + pos, data, avail);
+		data = (char const *)data + avail;
+		len -= avail;
+		shaHashBlock(ctx, ctx->data);
+	}
+	/* Full blocks */
+	while (len >= 64) {
+		shaHashBlock(ctx, data);
+		data = (char const *)data + 64;
+		len -= 64;
+	}
+	pos = 0;
+end:
+	/* Buffer trailing partial block */
+	memcpy((char *)ctx->data + pos, data, len);
+}
+
+void
+SHA1_Final(unsigned char hashout[20], SHA_CTX *ctx)
+{
+  static unsigned char const padding[64] = { 0x80, 0 /* more zeros */ };
+  uint32_t sizeL = ctx->sizeL;
+  uint32_t sizeH = ctx->sizeH;
+  int i;
+
+  /* Append final padding, leaving 8 bytes free */
+  SHA1_Update(ctx, padding, 64 - ((sizeL + 8) % 64));
+  ctx->data[14] = htonl(sizeH << 3 | sizeL >> 29);
+  ctx->data[15] = htonl(sizeL << 3);
+
+  shaHashBlock(ctx, ctx->data);
+
+  for (i = 0; i < 5; i++)
+  	((uint32_t *)hashout)[i] = htonl(ctx->hash[i]);
+
+   memset(ctx, 0, sizeof *ctx);
+}
+

Re: x86 asm SHA1 (draft)

[Junio C Hamano]

The series to revamp SHA1 is good but judging the merit of each
is outside my expertise, so I'd appreciate help to evaluate
these changes.  For example, I cannot choose between competing
three implementations for ppc without having access to a variety
of ppc machines, and even if I did, ppc is not what I normally
use, so incentive to try picking the best one for everybody is
relatively low on my part.

What we would want are obviously (1) no regression, (2) an easy
way for people who build git for their own machine to decide
which one suits them the best, and (3) an easy way to tell the
build mechanism to use the one that is chosen.

The only external interface for the set of SHA1 implementation
alternatives to the outside world is a well established SHA_CTX
type, and three functions SHA1_Init(), SHA1_Update() and
SHA1_Final(), and the alternative implementations are supposed
to be drop-in replaceable.

So let's do something like this:

 - When adding a new SHA1 implementation, we need to come up
   with a Makefile symbol (similar to PPC_SHA1, MOZILLA_SHA1 and
   friends) and set up the build machinery to use the one that
   is chosen;

 - We need a test program and a build rule in the Makefile that
   links with the chosen SHA1 implementation.

 - We need a test script that feeds the above program with known
   vectors to validate the SHA1 implementation (make sure the
   test covers large input to avoid the recent half-gig-limit
   problem), and bench the speed on the platform it was built.

 - If we wanted to go fancier, another script that builds all
   applicable alternatives on the building platform, run the
   bench for all of them and automatically pick the right one
   for the platform would be a plus.

We probably would want to collect the benchmark results from
popular platforms, have a summary to help people to choose a
sensible one in the toplevel INSTALL file, and include the raw
numbers in Documentation/technical/sha1-implementations.txt.

Once we go the above path, we may want to include both of the
the two new ppc implementations as separate choices as I
understand their performance depends on which ppc you are
talking about.

Any takers?

Re: x86 asm SHA1 (draft)

[linux]

> The series to revamp SHA1 is good but judging the merit of each
> is outside my expertise, so I'd appreciate help to evaluate
> these changes.  For example, I cannot choose between competing
> three implementations for ppc without having access to a variety
> of ppc machines, and even if I did, ppc is not what I normally
> use, so incentive to try picking the best one for everybody is
> relatively low on my part.

Well, I'm not sure it's worth this much trouble.  Both of my PPC
implementations are smaller and faster than the current one,
so that's a pretty easy decision.  The difference between them
is 2-3%, which is, I think, not enough to be worth the maintenance
burden of a run-time decision infrastructure.  Just pick either one
and call it a day.

> The only external interface for the set of SHA1 implementation
> alternatives to the outside world is a well established SHA_CTX
> type, and three functions SHA1_Init(), SHA1_Update() and
> SHA1_Final(), and the alternative implementations are supposed
> to be drop-in replaceable.

I'd prefer it it was an *opaque* SHA_CTX type.  Sometimes you can achieve
some useful benefits by rearranging the fields.  For example, keeping the
64-bit length field as a native-order 64-bit number when appropriate.
And sometimes it's useful to have the full 80-word W[] array, while
other implementations don't want it.

> We probably would want to collect the benchmark results from
> popular platforms, have a summary to help people to choose a
> sensible one in the toplevel INSTALL file, and include the raw
> numbers in Documentation/technical/sha1-implementations.txt.

Not that numbers are bad, but I think that until there's a real
need for more than a single good-enough version per instruction set,
this is excessive.  Does hashing even show up on a profile?

Re: x86 asm SHA1 (draft)

[Junio C Hamano]

linux@horizon.com writes:

> Well, I'm not sure it's worth this much trouble.  Both of my PPC
> implementations are smaller and faster than the current one,
> so that's a pretty easy decision.  The difference between them
> is 2-3%, which is, I think, not enough to be worth the maintenance
> burden of a run-time decision infrastructure.  Just pick either one
> and call it a day.
>...
> Not that numbers are bad, but I think that until there's a real
> need for more than a single good-enough version per instruction set,
> this is excessive.

OK.  I somehow got an impression that your two versions had
quite different performance characteristics on G4 and G5 and
there was a real choice.  If they are between a few per-cent,
then I agree it is not worth doing at all.

From b65bc21e7d8dc8cafc70dfa6354cb66b8874b2d9 Mon Sep 17 00:00:00 2001, [PATCH] Makefile: add framework to verify and bench sha1 implementations.

[Junio C Hamano, Junio C Hamano]

With this, you can say

	MOZILLA_SHA1=YesPlease make check-sha1 

to see how fast your favorite SHA-1 implementation is and if it
fails with small to huge inputs.

Signed-off-by: Junio C Hamano <junkio@cox.net>
---

 * As the maintainer, I do need people to see breakage before it
   happens, without having access to all the platforms, hence
   this.

 Makefile     |    6 ++++
 test-sha1.c  |   24 +++++++++++++++++
 test-sha1.sh |   83 ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
 3 files changed, 113 insertions(+), 0 deletions(-)

diff --git a/Makefile b/Makefile
index e29e3fa..ea0044d 100644
--- a/Makefile
+++ b/Makefile
@@ -636,6 +636,12 @@ test-delta$X: test-delta.c diff-delta.o 
 test-dump-cache-tree$X: dump-cache-tree.o $(GITLIBS)
 	$(CC) $(ALL_CFLAGS) -o $@ $(ALL_LDFLAGS) $(filter %.o,$^) $(LIBS)
 
+test-sha1$X: test-sha1.o $(GITLIBS)
+	$(CC) $(ALL_CFLAGS) -o $@ $(ALL_LDFLAGS) $(filter %.o,$^) $(LIBS)
+
+check-sha1:: test-sha1$X
+	./test-sha1.sh
+
 check:
 	for i in *.c; do sparse $(ALL_CFLAGS) $(SPARSE_FLAGS) $$i || exit; done
 
diff --git a/test-sha1.c b/test-sha1.c
new file mode 100644
index 0000000..2efc315
--- /dev/null
+++ b/test-sha1.c
@@ -0,0 +1,24 @@
+#include "cache.h"
+
+int main(int ac, char **av)
+{
+	SHA_CTX ctx;
+	unsigned char sha1[20];
+
+	SHA1_Init(&ctx);
+
+	while (1) {
+		ssize_t sz;
+		char buffer[8192];
+		sz = xread(0, buffer, sizeof(buffer));
+		if (sz == 0)
+			break;
+		if (sz < 0)
+			die("test-sha1: %s", strerror(errno));
+		SHA1_Update(&ctx, buffer, sz);
+	}
+	SHA1_Final(sha1, &ctx);
+	puts(sha1_to_hex(sha1));
+	exit(0);
+}
+
diff --git a/test-sha1.sh b/test-sha1.sh
new file mode 100755
index 0000000..01bbb57
--- /dev/null
+++ b/test-sha1.sh
@@ -0,0 +1,83 @@
+#!/bin/sh
+
+dd if=/dev/zero bs=1048576 count=100 2>/dev/null |
+/usr/bin/time ./test-sha1 >/dev/null
+
+while read expect cnt pfx
+do
+	case "$expect" in '#'*) continue ;; esac
+	actual=`
+		{
+			test -z "$pfx" || echo "$pfx"
+			dd if=/dev/zero bs=1048576 count=$cnt 2>/dev/null |
+			tr '[\0]' '[g]'
+		} | ./test-sha1
+	`
+	if test "$expect" = "$actual"
+	then
+		echo "OK: $expect $cnt $pfx"
+	else
+		echo >&2 "OOPS: $cnt"
+		echo >&2 "expect: $expect"
+		echo >&2 "actual: $actual"
+		exit 1
+	fi
+done <<EOF
+da39a3ee5e6b4b0d3255bfef95601890afd80709 0
+3f786850e387550fdab836ed7e6dc881de23001b 0 a
+5277cbb45a15902137d332d97e89cf8136545485 0 ab
+03cfd743661f07975fa2f1220c5194cbaff48451 0 abc
+3330b4373640f9e4604991e73c7e86bfd8da2dc3 0 abcd
+ec11312386ad561674f724b8cca7cf1796e26d1d 0 abcde
+bdc37c074ec4ee6050d68bc133c6b912f36474df 0 abcdef
+69bca99b923859f2dc486b55b87f49689b7358c7 0 abcdefg
+e414af7161c9554089f4106d6f1797ef14a73666 0 abcdefgh
+0707f2970043f9f7c22029482db27733deaec029 0 abcdefghi
+a4dd8aa74a5636728fe52451636e2e17726033aa 1
+9986b45e2f4d7086372533bb6953a8652fa3644a 1 frotz
+23d8d4f788e8526b4877548a32577543cbaaf51f 10
+8cd23f822ab44c7f481b8c92d591f6d1fcad431c 10 frotz
+f3b5604a4e604899c1233edb3bf1cc0ede4d8c32 512
+b095bd837a371593048136e429e9ac4b476e1bb3 512 frotz
+08fa81d6190948de5ccca3966340cc48c10cceac 1200 xyzzy
+e33a291f42c30a159733dd98b8b3e4ff34158ca0 4090 4G
+#a3bf783bc20caa958f6cb24dd140a7b21984838d 9999 nitfol
+EOF
+
+exit
+
+# generating test vectors
+# inputs are number of megabytes followed by some random string to prefix.
+
+while read cnt pfx
+do
+	actual=`
+		{
+			test -z "$pfx" || echo "$pfx"
+			dd if=/dev/zero bs=1048576 count=$cnt 2>/dev/null |
+			tr '[\0]' '[g]'
+		} | sha1sum |
+		sed -e 's/ .*//'
+	`
+	echo "$actual $cnt $pfx"
+done <<EOF
+0
+0 a
+0 ab
+0 abc
+0 abcd
+0 abcde
+0 abcdef
+0 abcdefg
+0 abcdefgh
+0 abcdefghi
+1
+1 frotz
+10
+10 frotz
+512
+512 frotz
+1200 xyzzy
+4090 4G
+9999 nitfol
+EOF
-- 
1.4.1.rc1.g0fca

Re: x86 asm SHA1 (draft)

[linux]

> OK.  I somehow got an impression that your two versions had
> quite different performance characteristics on G4 and G5 and
> there was a real choice.  If they are between a few per-cent,
> then I agree it is not worth doing at all.

My apologies for being unclear.

The place where a noticeable (if not disastrous) difference can appear
is x86, which has a lot more models with "interesting" performance
characteristics.  In particular, Intel is fond of building CPUs with a
very small "sweet spot".

The openssl SHA1 code had to be reworked to not suck on a P4, with the
resultant performance change:

#               compared with original  compared with Intel cc
#               assembler impl.         generated code
# Pentium       -16%                    +48%
# PIII/AMD      +8%                     +16%
# P4            +85%(!)                 +45%

The original code had the most popular round (what I call
ROUND_MIX(F2,...))) implemented as follows, with single-uop
instructions (no load+op) scheduled for the Pentium pipeline:
(A..E are working variables, S and T are temps)

	movl    16(%esp),S	U  \
        movl    24(%esp),T	 V  \
        xorl    S,T		U    \
        movl    48(%esp),S	 V    > "MIX", pentium-optimized
        xorl    S,T		U    /
        movl    4(%esp),S	 V  /
        xorl    S,T		U  /
        movl	B,S		 V
	roll	$1,T		U	Rotate of mix (SHA0 -> SHA1 fix)
	xor	C,S		 V
	mov	T,16(%esp)	U	Store back W[i]
	xor	D,S		 V	Finish computing F(B,C,D) = B^C^D
	lea	K(T,E),E	U	Add K and W[i] to E
	mov	A,T		 V
	roll	$5,T		UV
	rorl	$1,B		U
	add	S,E		 V
	rorl	$1,B		U
	add	T,E		 V

While the P4-optimized version goes:
	movl	B,S
	movl	16(%esp),T
	rorl	$2,B
	xorl	24(%esp),T
	xorl	C,S
	xorl	48(%esp),T
	xorl	D,S		This is F(B,C,D) = B^C^D
	xorl	4(%esp),T
	roll	$1,T		Rotate of mix (SHA0 -> SHA1 fix)
	addl	S,E
	movl	T,16(%esp)
	movl	A,S
	roll	$5,S
	lea	K(E,T),E
	add	S,E

(The original code actually rotates the working variables around 6
registers, not 5, but I've rearranged the last couple of instructions
to rotate around 5.)

Re: From b65bc21e7d8dc8cafc70dfa6354cb66b8874b2d9 Mon Sep 17 00:00:00 2001 [PATCH] Makefile: add framework to verify and bench sha1 implementations.

[linux]

Nice work, but I might point out that the original PPC SHA bug was hashing
more than 0.5G of contiguous data in a *single* call to SHA1_Update,
while your test program works with 8K buffers.

PPC SHA-1 Updates in "pu"

[Junio C Hamano]

Junio C Hamano <junkio@cox.net> writes:

> linux@horizon.com writes:
>
>> Well, I'm not sure it's worth this much trouble.  Both of my PPC
>> implementations are smaller and faster than the current one,
>> so that's a pretty easy decision.  The difference between them
>> is 2-3%, which is, I think, not enough to be worth the maintenance
>> burden of a run-time decision infrastructure.  Just pick either one
>> and call it a day.
>>...
>> Not that numbers are bad, but I think that until there's a real
>> need for more than a single good-enough version per instruction set,
>> this is excessive.
>
> OK.  I somehow got an impression that your two versions had
> quite different performance characteristics on G4 and G5 and
> there was a real choice.  If they are between a few per-cent,
> then I agree it is not worth doing at all.

If somebody has time and inclination, please try updated PPC SHA-1
from linux@horizon.com that is in "pu" (say make check-sha1) and
report impressions.

The first line from ./test-sha1.sh is the time output to hash 100MB
and there should be bunch of OK output to verify the code hashes
things correctly for inputs of various sizes.

Re: PPC SHA-1 Updates in "pu"

[Linus Torvalds]

On Sat, 24 Jun 2006, Junio C Hamano wrote:
> 
> If somebody has time and inclination, please try updated PPC SHA-1
> from linux@horizon.com that is in "pu" (say make check-sha1) and
> report impressions.

"make check-sha1" passes.

Before:
	[torvalds@g5 linux]$ /usr/bin/time git-fsck-objects --full
	101.90user 4.66system 1:46.72elapsed 99%CPU (0avgtext+0avgdata 0maxresident)k
	0inputs+0outputs (0major+1787158minor)pagefaults 0swaps

After:
	[torvalds@g5 linux]$ /usr/bin/time ~/git/git-fsck-objects --full
	101.16user 4.32system 1:45.56elapsed 99%CPU (0avgtext+0avgdata 0maxresident)k
	0inputs+0outputs (0major+1787127minor)pagefaults 0swaps

which doesn't seem to really imply anything seriously changed (in fact, 
rerunning it made the numbers even closer).

This is on a G5 powerpc.

Also, "pu" in general is totally unusable. It doesn't even compile.

I think that "Git.xs" thing is fine for random hacks, but please please 
PLEASE don't make any central program depend on it.

		Linus

Re: From b65bc21e7d8dc8cafc70dfa6354cb66b8874b2d9 Mon Sep 17 00:00:00 2001 [PATCH] Makefile: add framework to verify and bench sha1 implementations.

[Junio C Hamano]

linux@horizon.com writes:

> Nice work, but I might point out that the original PPC SHA bug was hashing
> more than 0.5G of contiguous data in a *single* call to SHA1_Update,
> while your test program works with 8K buffers.

Blush.  I realized it and updated the version in "pu" after I
sen the message.

Re: PPC SHA-1 Updates in "pu"

[Junio C Hamano]

Linus Torvalds <torvalds@osdl.org> writes:

> Also, "pu" in general is totally unusable. It doesn't even compile.

Care to share problems with Pasky and I to take a look at,
please?

> I think that "Git.xs" thing is fine for random hacks, but please please 
> PLEASE don't make any central program depend on it.

I agree.  I got really disgusted when I tentatively pulled the
current Git.xs into "next" and installed it for my own use to
notice that it broke git-fmt-merge-msg hence git-pull workflow.

Pasky, can we first iron out kinks in the build procedure and
installation before converting existing programs further?  The
things I worry about currently are:

 - the SITELIBARCH gotcha I sent you a message about (and you
   responded to it already -- was that an Acked-by?);

 - RPM target -- we probably acquired a new build-dependency in
   which case the .spec file needs to be updated;

 - Make sure Git.xs builds and installed result works fine on
   all platforms we care about, including Cygwin and other
   non-Linux boxes.

I'd even suggest we revert the changes to git-fmt-merge-msg to
keep it working for now, until the above worries are resolved.
Otherwise we cannot have it in "next" safely (and I REALLY _do_
want to have Git.pm infrastructure in "next" soonish).

We can start using Git.xs and friends in some _new_ ancillary
programs, once we solve building and installing problems for
everybody.  That way it would help us gain portability and
confidence without disrupting existing users.

Re: PPC SHA-1 Updates in "pu"

[Linus Torvalds]

On Sat, 24 Jun 2006, Junio C Hamano wrote:

> Linus Torvalds <torvalds@osdl.org> writes:
> 
> > Also, "pu" in general is totally unusable. It doesn't even compile.
> 
> Care to share problems with Pasky and I to take a look at,
> please?

Don't everybody see them?

	In file included from Git.xs:8:
	../cache.h:6:10: error: #include expects "FILENAME" or <FILENAME>
	In file included from /usr/lib/perl5/5.8.8/ppc-linux-thread-multi/CORE/perl.h:756,
	                 from Git.xs:15:
	/usr/lib/perl5/5.8.8/ppc-linux-thread-multi/CORE/embed.h:4195:1: warning: "die" redefined
	Git.xs:11:1: warning: this is the location of the previous definition
	Git.xs: In function 'boot_Git':
	Git.xs:57: warning: passing argument 1 of 'set_error_routine' from incompatible pointer type
	Git.xs:58: warning: passing argument 1 of 'set_die_routine' makes qualified function pointer from unqualified
	make[1]: *** [Git.o] Error 1
	make[1]: Leaving directory `/home/torvalds/git/perl'
	make: *** [all] Error 2

how does that compile for anybody else, when -DSHA1_HEADER isn't set 
correctly? The quotes have gone missing:

	-DSHA1_HEADER='ppc/sha1.h' 

don't ask me why.

		Linus

Re: PPC SHA-1 Updates in "pu"

[Junio C Hamano]

Linus Torvalds <torvalds@osdl.org> writes:

> Don't everybody see them?

No.  But I see it now.

> how does that compile for anybody else, when -DSHA1_HEADER isn't set 
> correctly? The quotes have gone missing:
>
> 	-DSHA1_HEADER='ppc/sha1.h' 
>
> don't ask me why.

That is, as usual, caused by careless shell quoting.

        : gitster; PPC_SHA1=YesPlease Meta/Make perl/Makefile
        GIT_VERSION = 1.4.1.rc1.g9adbe
        (cd perl && /usr/bin/perl Makefile.PL \
                        PREFIX="/home/junio/git-test" \
                        DEFINE="-O2 -Wall -Wdeclaration-after-statement
                        -g -fPIC -DSHA1_HEADER='"ppc/sha1.h"'
                        -DGIT_VERSION=\\\"1.4.1.rc1.g9adbe\\\"" \
                        LIBS="libgit.a xdiff/lib.a -lz")
        Unrecognized argument in LIBS ignored: 'libgit.a'
        Unrecognized argument in LIBS ignored: 'xdiff/lib.a'
        Writing Makefile for Git

All options but to use OpenSSL SHA-1 implementation share the
same problem (Meta/Make is a thin "make" wrapper to give USE_PIC
and other C compilation flags):

        : gitster; ARM_SHA1=YesPlease Meta/Make perl/Makefile
        (cd perl && /usr/bin/perl Makefile.PL \
                        PREFIX="/home/junio/git-test" \
                        DEFINE="-O2 -Wall -Wdeclaration-after-statement
                        -g -fPIC -DSHA1_HEADER='"arm/sha1.h"'
                        -DGIT_VERSION=\\\"1.4.1.rc1.g9adbe\\\"" \
                        LIBS="libgit.a xdiff/lib.a -lz")
        Unrecognized argument in LIBS ignored: 'libgit.a'
        Unrecognized argument in LIBS ignored: 'xdiff/lib.a'
        Writing Makefile for Git

        : gitster; MOZILLA_SHA1=YesPlease Meta/Make perl/Makefile
        (cd perl && /usr/bin/perl Makefile.PL \
                        PREFIX="/home/junio/git-test" \
                        DEFINE="-O2 -Wall -Wdeclaration-after-statement
                        -g -fPIC -DSHA1_HEADER='"mozilla-sha1/sha1.h"'
                        -DGIT_VERSION=\\\"1.4.1.rc1.g9adbe\\\"" \
                        LIBS="libgit.a xdiff/lib.a -lz")
        Unrecognized argument in LIBS ignored: 'libgit.a'
        Unrecognized argument in LIBS ignored: 'xdiff/lib.a'
        Writing Makefile for Git

Re: PPC SHA-1 Updates in "pu"

[Petr Baudis]

Dear diary, on Sun, Jun 25, 2006 at 01:59:16AM CEST, I got a letter
where Junio C Hamano <junkio@cox.net> said that...
> Linus Torvalds <torvalds@osdl.org> writes:
> 
> > how does that compile for anybody else, when -DSHA1_HEADER isn't set 
> > correctly? The quotes have gone missing:
> >
> > 	-DSHA1_HEADER='ppc/sha1.h' 
> >
> > don't ask me why.
> 
> That is, as usual, caused by careless shell quoting.
> 
>         : gitster; PPC_SHA1=YesPlease Meta/Make perl/Makefile
>         GIT_VERSION = 1.4.1.rc1.g9adbe
>         (cd perl && /usr/bin/perl Makefile.PL \
>                         PREFIX="/home/junio/git-test" \
>                         DEFINE="-O2 -Wall -Wdeclaration-after-statement
>                         -g -fPIC -DSHA1_HEADER='"ppc/sha1.h"'
>                         -DGIT_VERSION=\\\"1.4.1.rc1.g9adbe\\\"" \
>                         LIBS="libgit.a xdiff/lib.a -lz")
>         Unrecognized argument in LIBS ignored: 'libgit.a'
>         Unrecognized argument in LIBS ignored: 'xdiff/lib.a'
>         Writing Makefile for Git

Oops...

----

Git.pm build: Fix $DEFINE quoting and missing GIT-CFLAGS dependency

Signed-off-by: Petr Baudis <pasky@suse.cz>

diff --git a/Makefile b/Makefile
index 9a59466..64375f6 100644
--- a/Makefile
+++ b/Makefile
@@ -608,10 +608,12 @@ XDIFF_OBJS=xdiff/xdiffi.o xdiff/xprepare
 	rm -f $@ && $(AR) rcs $@ $(XDIFF_OBJS)
 
 
-perl/Makefile:	perl/Git.pm perl/Makefile.PL
+PERL_DEFINES = $(ALL_CFLAGS) -DGIT_VERSION='"$(GIT_VERSION)"'
+PERL_DEFINES_SQ = $(subst ','\'',$(PERL_DEFINES))
+perl/Makefile:	perl/Git.pm perl/Makefile.PL GIT-CFLAGS
 	(cd perl && $(PERL_PATH) Makefile.PL \
 		PREFIX="$(prefix)" \
-		DEFINE="$(ALL_CFLAGS) -DGIT_VERSION=\\\"$(GIT_VERSION)\\\"" \
+		DEFINE='$(PERL_DEFINES_SQ)' \
 		LIBS="$(EXTLIBS)")
 
 doc:

-- 
				Petr "Pasky" Baudis
Stuff: http://pasky.or.cz/
A person is just about as big as the things that make them angry.

Re: PPC SHA-1 Updates in "pu"

[Petr Baudis]

Dear diary, on Sat, Jun 24, 2006 at 10:21:30PM CEST, I got a letter
where Junio C Hamano <junkio@cox.net> said that...
> Pasky, can we first iron out kinks in the build procedure and
> installation before converting existing programs further?

Sure.

> The things I worry about currently are:
> 
>  - the SITELIBARCH gotcha I sent you a message about (and you
>    responded to it already -- was that an Acked-by?);

Yes. :-)

>  - RPM target -- we probably acquired a new build-dependency in
>    which case the .spec file needs to be updated;

Well, perl is currently not listed even as a runtime dependency,
so does it really need to be listed as a build dependency?

>  - Make sure Git.xs builds and installed result works fine on
>    all platforms we care about, including Cygwin and other
>    non-Linux boxes.

Unfortunately I don't have access to a lot of those. :-(

> I'd even suggest we revert the changes to git-fmt-merge-msg to
> keep it working for now, until the above worries are resolved.
> Otherwise we cannot have it in "next" safely (and I REALLY _do_
> want to have Git.pm infrastructure in "next" soonish).

Yes, that sounds reasonable.

> We can start using Git.xs and friends in some _new_ ancillary
> programs, once we solve building and installing problems for
> everybody.  That way it would help us gain portability and
> confidence without disrupting existing users.

Well, I don't think it's very likely that Git.pm per se would be buggy
on a certain specific platform - it should either work as well as
everywhere else or not build at all, in which case you have disrupted
the existing users anyway. :-) (But without disrupting anyone we won't
get any bugreports and never get it fixed.)

Perhaps other converted perl scripts can linger at least on the pu
branch?

-- 
				Petr "Pasky" Baudis
Stuff: http://pasky.or.cz/
A person is just about as big as the things that make them angry.

[PATCH] Git.pm build: Fix quoting and missing GIT-CFLAGS dependency

[Petr Baudis]

Signed-off-by: Petr Baudis <pasky@suse.cz>
---

  This one should do a better job; if we quote, let's do it proper. :-)

 Makefile |   12 ++++++++----
 1 files changed, 8 insertions(+), 4 deletions(-)

diff --git a/Makefile b/Makefile
index 9a59466..fb9ffad 100644
--- a/Makefile
+++ b/Makefile
@@ -608,11 +608,15 @@ XDIFF_OBJS=xdiff/xdiffi.o xdiff/xprepare
 	rm -f $@ && $(AR) rcs $@ $(XDIFF_OBJS)
 
 
-perl/Makefile:	perl/Git.pm perl/Makefile.PL
+PERL_DEFINE = $(ALL_CFLAGS) -DGIT_VERSION='"$(GIT_VERSION)"'
+PERL_DEFINE_SQ = $(subst ','\'',$(PERL_DEFINE))
+PERL_LIBS = $(EXTLIBS)
+PERL_LIBS_SQ = $(subst ','\'',$(PERL_LIBS))
+perl/Makefile:	perl/Git.pm perl/Makefile.PL GIT-CFLAGS
 	(cd perl && $(PERL_PATH) Makefile.PL \
-		PREFIX="$(prefix)" \
-		DEFINE="$(ALL_CFLAGS) -DGIT_VERSION=\\\"$(GIT_VERSION)\\\"" \
-		LIBS="$(EXTLIBS)")
+		PREFIX='$(prefix_SQ)' \
+		DEFINE='$(PERL_DEFINE_SQ)' \
+		LIBS='$(PERL_LIBS)')
 
 doc:
 	$(MAKE) -C Documentation all

-- 
				Petr "Pasky" Baudis
Stuff: http://pasky.or.cz/
A person is just about as big as the things that make them angry.

Re: [PATCH] Git.pm build: Fix quoting and missing GIT-CFLAGS dependency

[Junio C Hamano]

Petr Baudis <pasky@suse.cz> writes:

>   This one should do a better job; if we quote, let's do it proper. :-)
>
> +PERL_DEFINE = $(ALL_CFLAGS) -DGIT_VERSION='"$(GIT_VERSION)"'
> +PERL_DEFINE_SQ = $(subst ','\'',$(PERL_DEFINE))
> +PERL_LIBS = $(EXTLIBS)
> +PERL_LIBS_SQ = $(subst ','\'',$(PERL_LIBS))
> +perl/Makefile:	perl/Git.pm perl/Makefile.PL GIT-CFLAGS
>  	(cd perl && $(PERL_PATH) Makefile.PL \
> +		PREFIX='$(prefix_SQ)' \
> +		DEFINE='$(PERL_DEFINE_SQ)' \
> +		LIBS='$(PERL_LIBS)')

Yes let's ;-).  You obviously meant PERL_LIBS_SQ on the last line.

During our a handful piecemeal patch exchange back-and-forth on
the list, most of the patches did not apply mechanically, so I
rolled them up and have pushed out the result in "pu" and it
will mirror out shortly.  I am reasonably sure it is in much
better shape than 24 hours ago; could you double check the
result for me please?

And I earlier said...

    Pasky, can we first iron out kinks in the build procedure and
    installation before converting existing programs further?  The
    things I worry about currently are:

     - the SITELIBARCH gotcha I sent you a message about (and you
       responded to it already -- was that an Acked-by?);

     - RPM target -- we probably acquired a new build-dependency in
       which case the .spec file needs to be updated;

     - Make sure Git.xs builds and installed result works fine on
       all platforms we care about, including Cygwin and other
       non-Linux boxes.

    I'd even suggest we revert the changes to git-fmt-merge-msg to
    keep it working for now, until the above worries are resolved.
    Otherwise we cannot have it in "next" safely (and I REALLY _do_
    want to have Git.pm infrastructure in "next" soonish).

    We can start using Git.xs and friends in some _new_ ancillary
    programs, once we solve building and installing problems for
    everybody.  That way it would help us gain portability and
    confidence without disrupting existing users.

I think we have cleared SITELIBARCH, and Git.xs building is in
testable state for wider audience.  The remaining hurdles are to
make sure the RPM target is still sensible, and fix the test
scheme.

Now, I am clueless about RPM, so help is very much appreciated.

About the testsuite, I think with the way git-fmt-merge-msg (and
other Perl scripts that will use Git.pm) is munged on the
initial line "#!/usr/bin/perl -I$(installedpath)", the test
scheme is seriously broken.  To see how yourself, have a good
working version of Git.pm and friends in the path your
git-fmt-merge-msg's first line points at, apply the following
patch to perl/Git.pm in your source tree and run "make test".
It will pass t5700-clone-reference.sh test, which does "git
pull" (and uses git-fmt-merge-msg) without problems X-<.

diff --git a/perl/Git.pm b/perl/Git.pm
index 7bbb5be..c9121f4 100644
--- a/perl/Git.pm
+++ b/perl/Git.pm
@@ -1,3 +1,5 @@
+syntax error
+
 =head1 NAME
 
 Git - Perl interface to the Git version control system

This is (as I said in a separate message earlier) because -I on
the first line (and the command line) seems to take precedence
over PERL5LIB we set up in the test harness, so the test does
not find the broken version you think you are testing.  And
after it tests out OK, you install it and suffer from the
breakage.  This is bad.

I am not sure what the right way to fix it, though.  Obviously,
we could do something like the following:

diff --git a/Makefile b/Makefile
index 3a67578..3350be3 100644
--- a/Makefile
+++ b/Makefile
@@ -517,9 +517,12 @@ common-cmds.h: Documentation/git-*.txt
 	chmod +x $@+
 	mv $@+ $@
 
-$(patsubst %.perl,%,$(SCRIPT_PERL)) : % : %.perl
+$(patsubst %.perl,%,$(SCRIPT_PERL)): perl/Makefile
+$(patsubst %.perl,%,$(SCRIPT_PERL)): % : %.perl
 	rm -f $@ $@+
-	sed -e '1s|#!.*perl\(.*\)|#!$(PERL_PATH_SQ)\1 -I'"$$(make -s -C perl instlibdir)"'|' \
+	INSTLIBDIR=$$(make -s -C perl instlibdir) && \
+	sed -e '1s|#!.*perl\(.*\)|#!$(PERL_PATH_SQ)\1|' \
+	    -e 's|@@INSTLIBDIR@@|'"$$INSTLIBDIR"'|g' \
 	    -e 's/@@GIT_VERSION@@/$(GIT_VERSION)/g' \
 	    $@.perl >$@+
 	chmod +x $@+
diff --git a/git-fmt-merge-msg.perl b/git-fmt-merge-msg.perl
index f86231e..e8fad02 100755
--- a/git-fmt-merge-msg.perl
+++ b/git-fmt-merge-msg.perl
@@ -5,6 +5,7 @@ #
 # Read .git/FETCH_HEAD and make a human readable merge message
 # by grouping branches and tags together to form a single line.
 
+unshift @INC, '@@INSTLIBDIR@@';
 use strict;
 use Git;
 use Error qw(:try);

which is in line with what git-merge-recursive does, but it is
not really what usual Perl modules and scripts do.  It is
bending backwards to support testing which does not feel right.

The additional dependency to perl/Makefile is needed regardless
of this tentative fix -- you cannot run make -C perl before
building perl/Makefile.

Re: PPC SHA-1 Updates in "pu"

[Junio C Hamano]

Petr Baudis <pasky@suse.cz> writes:

>>  - RPM target -- we probably acquired a new build-dependency in
>>    which case the .spec file needs to be updated;
>
> Well, perl is currently not listed even as a runtime dependency,
> so does it really need to be listed as a build dependency?

Really?  I think rpmbuild is getting anything that matches "^use "
and listing the perl modules as dependencies.

>>  - Make sure Git.xs builds and installed result works fine on
>>    all platforms we care about, including Cygwin and other
>>    non-Linux boxes.
>
> Unfortunately I don't have access to a lot of those. :-(

I don't either.  That's why I would want to place something
low-impact on "next" to ask help from the users.

>> I'd even suggest we revert the changes to git-fmt-merge-msg to
>> keep it working for now, until the above worries are resolved.
>> Otherwise we cannot have it in "next" safely (and I REALLY _do_
>> want to have Git.pm infrastructure in "next" soonish).
>
> Yes, that sounds reasonable.
>
>> We can start using Git.xs and friends in some _new_ ancillary
>> programs, once we solve building and installing problems for
>> everybody.  That way it would help us gain portability and
>> confidence without disrupting existing users.
>
> Well, I don't think it's very likely that Git.pm per se would be buggy
> on a certain specific platform - it should either work as well as
> everywhere else or not build at all, in which case you have disrupted
> the existing users anyway. :-) (But without disrupting anyone we won't
> get any bugreports and never get it fixed.)
>
> Perhaps other converted perl scripts can linger at least on the pu
> branch?

My preference is to keep your other conversion in "later"
mailbox, not even in "pu", to keep them from distracting me.
I'd like to have something low-impact (e.g. "git-mv" which I do
not use and I do not think Linus uses) along with the perl/
directory and build procedure in "next" soonish to make sure at
least things build and correctly install for everybody
(compiling and linking alone would not count as "correctly
install" while we have something like INSTALLSITEARCH gotcha).
After we are reasonably confident about the whole .xs stuff we
can revert the revert of git-fmt-merge-msg.

Re: PPC SHA-1 Updates in "pu"

[Petr Baudis]

Dear diary, on Sun, Jun 25, 2006 at 05:57:33AM CEST, I got a letter
where Junio C Hamano <junkio@cox.net> said that...
> Petr Baudis <pasky@suse.cz> writes:
> 
> >>  - RPM target -- we probably acquired a new build-dependency in
> >>    which case the .spec file needs to be updated;
> >
> > Well, perl is currently not listed even as a runtime dependency,
> > so does it really need to be listed as a build dependency?
> 
> Really?  I think rpmbuild is getting anything that matches "^use "
> and listing the perl modules as dependencies.

I had on my mind to depend only on modules that are part of the default
Perl distribution, since installing them from CPAN is a bother if you
are installing Git to your home directory. That is why we bundle Error.

All the modules we depend on should come bundled with Perl since 5.8.1.
Now, I'm not sure what our "cutoff" point is, and even if it is
something like 5.6.0 whether we can just require users of Perl older
than 5.8.1 (which should be only some rare and obscure systems anyway)
to install the modules from CPAN.

If not, we can just get rid of Scalar::Util and XSLoader and we should
be clean; XSLoader should be easy, Scalar::Util somewhat more messy
since we will have to get Error.pm own .xs as well.

-- 
				Petr "Pasky" Baudis
Stuff: http://pasky.or.cz/
A person is just about as big as the things that make them angry.

Re: PPC SHA-1 Updates in "pu"

[Johannes Schindelin]

Hi,

On Sun, 25 Jun 2006, Petr Baudis wrote:

> All the modules we depend on should come bundled with Perl since 5.8.1.
> Now, I'm not sure what our "cutoff" point is, and even if it is
> something like 5.6.0 whether we can just require users of Perl older
> than 5.8.1 (which should be only some rare and obscure systems anyway)
> to install the modules from CPAN.

NO! It is _wrong_ to require users to upgrade, when a little more work on 
our side would fix it. Requiring users to upgrade is a proactive way to 
get rid of new users.

And old ones. If you would require me to upgrade to Perl 5.8.1, I would 
rather stop upgrading git. Hell, something I really like about git: I just 
download the tar.gz, unpack it, and type make install. And usually that 
Just Works. (Except MinGW32, but I have already managed to see a nice 
"git-log -p" with it.)

Ciao,
Dscho

Re: PPC SHA-1 Updates in "pu"

[Petr Baudis]

  Hi,

Dear diary, on Sun, Jun 25, 2006 at 12:07:21PM CEST, I got a letter
where Johannes Schindelin <Johannes.Schindelin@gmx.de> said that...
> On Sun, 25 Jun 2006, Petr Baudis wrote:
> 
> > All the modules we depend on should come bundled with Perl since 5.8.1.
> > Now, I'm not sure what our "cutoff" point is, and even if it is
> > something like 5.6.0 whether we can just require users of Perl older
> > than 5.8.1 (which should be only some rare and obscure systems anyway)
> > to install the modules from CPAN.
> 
> NO! It is _wrong_ to require users to upgrade, when a little more work on 
> our side would fix it. Requiring users to upgrade is a proactive way to 
> get rid of new users.
> 
> And old ones. If you would require me to upgrade to Perl 5.8.1, I would 
> rather stop upgrading git.

  please read it again - I'm not requiring you to upgrade to Perl 5.8.1.
I'm just saying that if you have Perl older than 5.8.1, you might need
to install some extra modules from CPAN.

  Now, if that's not acceptable either that's fine by me and I can
adapt, I just need to know at which point we _will_ require you to
upgrade or install extra modules.

-- 
				Petr "Pasky" Baudis
Stuff: http://pasky.or.cz/
A person is just about as big as the things that make them angry.

Re: PPC SHA-1 Updates in "pu"

[Junio C Hamano]

Petr Baudis <pasky@suse.cz> writes:

>> And old ones. If you would require me to upgrade to Perl 5.8.1, I would 
>> rather stop upgrading git.
>
>   please read it again - I'm not requiring you to upgrade to Perl 5.8.1.
> I'm just saying that if you have Perl older than 5.8.1, you might need
> to install some extra modules from CPAN.
>
>   Now, if that's not acceptable either that's fine by me and I can
> adapt, I just need to know at which point we _will_ require you to
> upgrade or install extra modules.

I vaguely recall that last time we discussed the minimum Perl
version requirement somebody perhaps Merlyn said 5.6 is old
enough but in some corporate settings people may still be stuck
with 5.004.

Tentatively let's say our cut-off point is somewhere around 5.6.
If we can get away without relying on extra from CPAN that would
be great.  Otherwise as long as the modules from CPAN we end up
depending on are all compatible with the cut-off version of Perl
that would be acceptable.  We might even try to be nicer and
carry a straight copy of what we require from CPAN in compat/
just like we have subprocess.py there (modulo licensing worries
if any, of course).

Johannes, Linus and the list, would that be a good enough
guideline?

Re: PPC SHA-1 Updates in "pu"

[Johannes Schindelin]

Hi,

On Sun, 25 Jun 2006, Junio C Hamano wrote:

> I vaguely recall that last time we discussed the minimum Perl
> version requirement somebody perhaps Merlyn said 5.6 is old
> enough but in some corporate settings people may still be stuck
> with 5.004.
> 
> Tentatively let's say our cut-off point is somewhere around 5.6.
> If we can get away without relying on extra from CPAN that would
> be great.  Otherwise as long as the modules from CPAN we end up
> depending on are all compatible with the cut-off version of Perl
> that would be acceptable.  We might even try to be nicer and
> carry a straight copy of what we require from CPAN in compat/
> just like we have subprocess.py there (modulo licensing worries
> if any, of course).

I can live with it. Although I still think that it would be a good idea to 
convert (at least the most commonly used) scripts to C.

Perl, Python and sometimes even bash are good for fast prototyping. But 
for serious work, such as profiling, they are not that good.

And you can see different behaviour on different platforms (plus things 
like the SunCC requirement for XS on Solaris), which make the scripts less 
robust.

Ciao,
Dscho

Re: [PATCH] Git.pm build: Fix quoting and missing GIT-CFLAGS dependency

[Petr Baudis]

Dear diary, on Sun, Jun 25, 2006 at 05:03:24AM CEST, I got a letter
where Junio C Hamano <junkio@cox.net> said that...
> During our a handful piecemeal patch exchange back-and-forth on
> the list, most of the patches did not apply mechanically, so I
> rolled them up and have pushed out the result in "pu" and it
> will mirror out shortly.  I am reasonably sure it is in much
> better shape than 24 hours ago; could you double check the
> result for me please?

It looks good; I don't like the makefile changes a lot but more on that
below.

Could you please also throw in these two?

[PATCH 3/7] Git.pm: Swap hash_object() parameters
[PATCH 4/7] Git.pm: Fix Git->repository("/somewhere/totally/elsewhere")

..snip..
>      - RPM target -- we probably acquired a new build-dependency in
>        which case the .spec file needs to be updated;
..snip..
> I think we have cleared SITELIBARCH, and Git.xs building is in
> testable state for wider audience.  The remaining hurdles are to
> make sure the RPM target is still sensible, and fix the test
> scheme.
> 
> Now, I am clueless about RPM, so help is very much appreciated.

Chris, could you help, please? Do we need to insert anything special
to builddeps if we build own Perl module?

> About the testsuite, I think with the way git-fmt-merge-msg (and
> other Perl scripts that will use Git.pm) is munged on the
> initial line "#!/usr/bin/perl -I$(installedpath)", the test
> scheme is seriously broken.  To see how yourself, have a good
> working version of Git.pm and friends in the path your
> git-fmt-merge-msg's first line points at, apply the following
> patch to perl/Git.pm in your source tree and run "make test".
> It will pass t5700-clone-reference.sh test, which does "git
> pull" (and uses git-fmt-merge-msg) without problems X-<.

Yes, -I is very broken. I have abandoned it in:

	Subject: Re: [PATCH 01/12] Introduce Git.pm (v4)
	Date:   Sat, 24 Jun 2006 13:52:27 +0200

The advantage to your approach is that it works properly without
requiring to make install even outside of the testsuite.

> The additional dependency to perl/Makefile is needed regardless
> of this tentative fix -- you cannot run make -C perl before
> building perl/Makefile.

Yes, that bit shall be Acked-by: Petr Baudis <pasky@suse.cz>

-- 
				Petr "Pasky" Baudis
Stuff: http://pasky.or.cz/
A person is just about as big as the things that make them angry.

Re: PPC SHA-1 Updates in "pu"

[Randal L. Schwartz]

>>>>> "Johannes" == Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:

Johannes> Perl, Python and sometimes even bash are good for fast
Johannes> prototyping. But for serious work, such as profiling, they are not
Johannes> that good.

Allow my to register my strong disagreement to that statement, but then I'll
crawl back in my hole.

-- 
Randal L. Schwartz - Stonehenge Consulting Services, Inc. - +1 503 777 0095
<merlyn@stonehenge.com> <URL:http://www.stonehenge.com/merlyn/>
Perl/Unix/security consulting, Technical writing, Comedy, etc. etc.
See PerlTraining.Stonehenge.com for onsite and open-enrollment Perl training!

Re: PPC SHA-1 Updates in "pu"

[Johannes Schindelin]

Hi,

On Sun, 25 Jun 2006, Randal L. Schwartz wrote:

> >>>>> "Johannes" == Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
> 
> Johannes> Perl, Python and sometimes even bash are good for fast
> Johannes> prototyping. But for serious work, such as profiling, they are not
> Johannes> that good.
> 
> Allow my to register my strong disagreement to that statement, but then I'll
> crawl back in my hole.

Which statement do you mean? The "good for fast prototyping" one? ;-)

Being our friendly local Perl wizard, who could code cvsserver as a Perl 
one-liner, you probably want to say that profiling Perl is easy. Can you 
enlighten me how to do memory _and_ timing profiling on, say, a per-line 
basis?

Ciao,
Dscho

perl profiling (was: PPC SHA-1 Updates in "pu")

[Jeff King]

On Mon, Jun 26, 2006 at 01:23:21AM +0200, Johannes Schindelin wrote:

> one-liner, you probably want to say that profiling Perl is easy. Can you 
> enlighten me how to do memory _and_ timing profiling on, say, a per-line 
> basis?

For the timing, have you tried using Devel::SmallProf?
  perl -d:SmallProf foo.pl

-Peff

Re: [PATCH] Git.pm build: Fix quoting and missing GIT-CFLAGS dependency

[Junio C Hamano]

Petr Baudis <pasky@suse.cz> writes:

> Could you please also throw in these two?
>
> [PATCH 3/7] Git.pm: Swap hash_object() parameters
> [PATCH 4/7] Git.pm: Fix Git->repository("/somewhere/totally/elsewhere")

Will take a look.

> Yes, -I is very broken. I have abandoned it in:
>
> 	Subject: Re: [PATCH 01/12] Introduce Git.pm (v4)
> 	Date:   Sat, 24 Jun 2006 13:52:27 +0200
>
> The advantage to your approach is that it works properly without
> requiring to make install even outside of the testsuite.

I remember myself getting utterly discusted when I saw the
inclusion of the build-time blib directory in the search path in
some other Perl code outside git.

Worse yet, I suspect the order you do the two directories is
wrong to prefer the freshly built one over the one you installed
the last time, but I was trying not to stare at too much for
health reasons so ... ;-).

Re: PPC SHA-1 Updates in "pu"

[Junio C Hamano]

Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:

> I can live with it. Although I still think that it would be a good idea to 
> convert (at least the most commonly used) scripts to C.
>
> Perl, Python and sometimes even bash are good for fast prototyping. But 
> for serious work, such as profiling, they are not that good.

I expect the eventual primary customer of Git.xs to be gitweb.

I do not necessarily agree with what you just said about
scripting languages.  Shell is a very good implementation
language for certain serious things that does not require
performance and non command line UI.

> And you can see different behaviour on different platforms (plus things 
> like the SunCC requirement for XS on Solaris), which make the scripts less 
> robust.

I am not sure about "less robust" part, but it certainly
involves initial pain to deal with portability across platforms.

That's why I want to make sure that the basics is sound before
we spend too much time and attention on converting existing
scripts.  I think the major part of bringing Git.xs series
acceptably mergeable is not about XS programming and Perl script
conversion, but primarily about the work on the build
infrastructure (Makefile, test scripts and .spec).

GIt.xs merge status

[Junio C Hamano]

Junio C Hamano <junkio@cox.net> writes:

> Pasky, can we first iron out kinks in the build procedure and
> installation before converting existing programs further?  The
> things I worry about currently are:
>
>  - the SITELIBARCH gotcha I sent you a message about (and you
>    responded to it already -- was that an Acked-by?);

I think this finally was cleared thanks to Pavel Roskin (and an
unrelated workaround at the tip of "pu" by me).

>  - RPM target -- we probably acquired a new build-dependency in
>    which case the .spec file needs to be updated;

I am having trouble with this.  I'd appreciate help from RPM
savvy people (the build failure log at the end).

>  - Make sure Git.xs builds and installed result works fine on
>    all platforms we care about, including Cygwin and other
>    non-Linux boxes.

Help wanted from the list here.  One thing to note is that I
understand Pasky is working on not using Devel::PPPort to make
the code work with 5.6, so if your build dies with problems in
that area you might want to wait until that is fixed.

> I'd even suggest we revert the changes to git-fmt-merge-msg to
> keep it working for now, until the above worries are resolved.
> Otherwise we cannot have it in "next" safely (and I REALLY _do_
> want to have Git.pm infrastructure in "next" soonish).

I am still undecided about the reverting, since in the places I
personally care about the program works ;-).

I test-built the tip of "pu" 57628f0e; the RPM build log ends
like this:

Requires(rpmlib): rpmlib(CompressedFileNames) <= 3.0.4-1 rpmlib(PayloadFilesHavePrefix) <= 4.0-1
Requires: /bin/sh git-core = 1.4.1.rc2.g5762-1 tk >= 8.4
Processing files: git-debuginfo-1.4.1.rc2.g5762-1
Provides: Git.so.debug()(64bit)
Requires(rpmlib): rpmlib(CompressedFileNames) <= 3.0.4-1 rpmlib(PayloadFilesHavePrefix) <= 4.0-1
Checking for unpackaged file(s): /usr/lib/rpm/check-files /var/tmp/git-1.4.1.rc2.g5762-1-root-junio
error: Installed (but unpackaged) file(s) found:
   /usr/lib64/perl5/5.8.6/x86_64-linux-thread-multi/perllocal.pod
   /usr/lib64/perl5/site_perl/5.8.6/x86_64-linux-thread-multi/Error.pm
   /usr/lib64/perl5/site_perl/5.8.6/x86_64-linux-thread-multi/Git.pm
   /usr/lib64/perl5/site_perl/5.8.6/x86_64-linux-thread-multi/auto/Git/.packlist
   /usr/lib64/perl5/site_perl/5.8.6/x86_64-linux-thread-multi/auto/Git/Git.bs
   /usr/lib64/perl5/site_perl/5.8.6/x86_64-linux-thread-multi/auto/Git/Git.so


RPM build errors:
    Installed (but unpackaged) file(s) found:
   /usr/lib64/perl5/5.8.6/x86_64-linux-thread-multi/perllocal.pod
   /usr/lib64/perl5/site_perl/5.8.6/x86_64-linux-thread-multi/Error.pm
   /usr/lib64/perl5/site_perl/5.8.6/x86_64-linux-thread-multi/Git.pm
   /usr/lib64/perl5/site_perl/5.8.6/x86_64-linux-thread-multi/auto/Git/.packlist
   /usr/lib64/perl5/site_perl/5.8.6/x86_64-linux-thread-multi/auto/Git/Git.bs
   /usr/lib64/perl5/site_perl/5.8.6/x86_64-linux-thread-multi/auto/Git/Git.so
make: *** [rpm] Error 1

Re: GIt.xs merge status

[Pavel Roskin]

On Thu, 2006-06-29 at 18:28 -0700, Junio C Hamano wrote:
> Checking for unpackaged file(s): /usr/lib/rpm/check-files /var/tmp/git-1.4.1.rc2.g5762-1-root-junio
> error: Installed (but unpackaged) file(s) found:
>    /usr/lib64/perl5/5.8.6/x86_64-linux-thread-multi/perllocal.pod
>    /usr/lib64/perl5/site_perl/5.8.6/x86_64-linux-thread-multi/Error.pm
>    /usr/lib64/perl5/site_perl/5.8.6/x86_64-linux-thread-multi/Git.pm
>    /usr/lib64/perl5/site_perl/5.8.6/x86_64-linux-thread-multi/auto/Git/.packlist
>    /usr/lib64/perl5/site_perl/5.8.6/x86_64-linux-thread-multi/auto/Git/Git.bs
>    /usr/lib64/perl5/site_perl/5.8.6/x86_64-linux-thread-multi/auto/Git/Git.so

I guess all this perl stuff should be in a separate module perl-Git to
comply with Red Hat conventions.  This would make git-core depend on
perl-Git, but it's OK.

Error.pm is already provided by perl-Error.  If we require perl(Error)
for building, it won't be installed.  Actually, probing for Error.pm is
incorrect, so I'm fixing it.

Git.bs, .packlist and perllocal.pod should be removed - that's what
other Perl packages do.  Red Hat packages use INSTALLDIRS=vendor so that
"site_perl" becomes "vendor_perl".

While hacking that, I have wound that "--without doc" is broken in pu,
so I'm fixing it as well.  The patches will be sent shortly.

-- 
Regards,
Pavel Roskin

Re: Git.xs merge status

[Junio C Hamano]

Pavel Roskin <proski@gnu.org> writes:

> I guess all this perl stuff should be in a separate module perl-Git to
> comply with Red Hat conventions.  This would make git-core depend on
> perl-Git, but it's OK.
>
> Error.pm is already provided by perl-Error.  If we require perl(Error)
> for building, it won't be installed.  Actually, probing for Error.pm is
> incorrect, so I'm fixing it.
>
> Git.bs, .packlist and perllocal.pod should be removed - that's what
> other Perl packages do.  Red Hat packages use INSTALLDIRS=vendor so that
> "site_perl" becomes "vendor_perl".
>
> While hacking that, I have wound that "--without doc" is broken in pu,
> so I'm fixing it as well.  The patches will be sent shortly.

Thanks.

The kernel.org machine I am using for testing does not seem to
have perl-Error installed, and I suspect Pasky arranged to ship
our own Error.pm for people building git from source because the
package is not so widely installed.  I guess I should ask the
admins there before I can build perl-Git RPMs for release. 

I am doing this preparation not for the upcoming 1.4.1 but later
than that -- perhaps way later than that -- so there is no rush.

Re: Git.xs merge status

[Pavel Roskin]

Quoting Junio C Hamano <junkio@cox.net>:

> The kernel.org machine I am using for testing does not seem to
> have perl-Error installed, and I suspect Pasky arranged to ship
> our own Error.pm for people building git from source because the
> package is not so widely installed.  I guess I should ask the
> admins there before I can build perl-Git RPMs for release.

It's better than to have conflicting packages (perl-Git and perl-Error).  The
build requirement can be relaxed if needed (either by finding and removing
Error* after the install or by adding another flag to Makefile.PL), but I think
it's logical to have it because perl-Error would be needed by git-core anyway.

Another solution would be to arrange Error.pm to be installed and used as
Git::Error, but that would be a case of code duplication.

--
Regards,
Pavel Roskin

Re: GIt.xs merge status

[Johannes Schindelin]

Hi,

On Thu, 29 Jun 2006, Junio C Hamano wrote:

> Junio C Hamano <junkio@cox.net> writes:
> 
> >  - Make sure Git.xs builds and installed result works fine on
> >    all platforms we care about, including Cygwin and other
> >    non-Linux boxes.
> 
> Help wanted from the list here.  One thing to note is that I
> understand Pasky is working on not using Devel::PPPort to make
> the code work with 5.6, so if your build dies with problems in
> that area you might want to wait until that is fixed.

I'll try it (it's in pu, right?). Note that breaking git-fmt-merge-msg 
might be a good way to force somebody to rewrite it in C ;-)

Note that on my iBook (where I reported the Devel::PPPort problem), I _do_ 
have perl modules compiled from source, using SWIG. So, there _should_ be 
no problem to get it to run (although I have problems with my eyes ever 
since I looked into the code generated by SWIG).

Ciao,
Dscho

Re: GIt.xs merge status

[Junio C Hamano]

Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:

> I'll try it (it's in pu, right?). Note that breaking git-fmt-merge-msg 
> might be a good way to force somebody to rewrite it in C ;-)

It would hopefully not come to that (and that is I am playing
safe and keeping the series in "pu"), and even if it did, I am
hoping that Perl is so ubiquitous that people would fix it up
quickly.

[POOL] Who likes running Git without make install?

[Petr Baudis]

Dear diary, on Mon, Jun 26, 2006 at 08:48:31AM CEST, I got a letter
where Junio C Hamano <junkio@cox.net> said that...
> I remember myself getting utterly discusted when I saw the
> inclusion of the build-time blib directory in the search path in
> some other Perl code outside git.

Well, yes, it is ugly, but it was really cool that we could have used
Git without installing it anywhere.

But perhaps that's just me refusing to break his old ways of doing
things. Does anyone else care about it? (And why?)

> Worse yet, I suspect the order you do the two directories is
> wrong to prefer the freshly built one over the one you installed
> the last time, but I was trying not to stare at too much for
> health reasons so ... ;-).

Oh man, of course you are right. :-)

-- 
				Petr "Pasky" Baudis
Stuff: http://pasky.or.cz/
Snow falling on Perl. White noise covering line noise.
Hides all the bugs too. -- J. Putnam

Re: [POOL] Who likes running Git without make install?

[Junio C Hamano]

Petr Baudis <pasky@suse.cz> writes:

> Dear diary, on Mon, Jun 26, 2006 at 08:48:31AM CEST, I got a letter
> where Junio C Hamano <junkio@cox.net> said that...
>> I remember myself getting utterly discusted when I saw the
>> inclusion of the build-time blib directory in the search path in
>> some other Perl code outside git.
>
> Well, yes, it is ugly, but it was really cool that we could have used
> Git without installing it anywhere.
>
> But perhaps that's just me refusing to break his old ways of doing
> things. Does anyone else care about it? (And why?)
>
>> Worse yet, I suspect the order you do the two directories is
>> wrong to prefer the freshly built one over the one you installed
>> the last time, but I was trying not to stare at too much for
>> health reasons so ... ;-).
>
> Oh man, of course you are right. :-)

That's fixed in ancient past in git timescale.  Why are you
bringing it up again? ;-)

Re: [POOL] Who likes running Git without make install?

[Junio C Hamano]

Petr Baudis <pasky@suse.cz> writes:

> Dear diary, on Mon, Jun 26, 2006 at 08:48:31AM CEST, I got a letter
> where Junio C Hamano <junkio@cox.net> said that...
>> I remember myself getting utterly discusted when I saw the
>> inclusion of the build-time blib directory in the search path in
>> some other Perl code outside git.
>
> Well, yes, it is ugly, but it was really cool that we could have used
> Git without installing it anywhere.
>
> But perhaps that's just me refusing to break his old ways of doing
> things. Does anyone else care about it? (And why?)

Well, for a quick test to see if I haven't broken anything, I
use a new shell and do ". ./+denv" in my git repository where
that file has something like this:

        $ cat ./+denv
        :

        GIT_EXEC_PATH=`pwd`
        PATH=`pwd`:/usr/bin:/bin

        export GIT_EXEC_PATH PATH

So to a certain degree, yes I do care.

Re: [POOL] Who likes running Git without make install?

[Petr Baudis]

Dear diary, on Sun, Jul 02, 2006 at 02:05:46AM CEST, I got a letter
where Junio C Hamano <junkio@cox.net> said that...
> That's fixed in ancient past in git timescale.  Why are you
> bringing it up again? ;-)

Because, it is, well, not fixed? ;-) (Apparently.)

Dear diary, on Sun, Jul 02, 2006 at 02:08:07AM CEST, I got a letter
where Junio C Hamano <junkio@cox.net> said that...
> Petr Baudis <pasky@suse.cz> writes:
> 
> > Dear diary, on Mon, Jun 26, 2006 at 08:48:31AM CEST, I got a letter
> > where Junio C Hamano <junkio@cox.net> said that...
> >> I remember myself getting utterly discusted when I saw the
> >> inclusion of the build-time blib directory in the search path in
> >> some other Perl code outside git.
> >
> > Well, yes, it is ugly, but it was really cool that we could have used
> > Git without installing it anywhere.
> >
> > But perhaps that's just me refusing to break his old ways of doing
> > things. Does anyone else care about it? (And why?)
> 
> Well, for a quick test to see if I haven't broken anything, I
> use a new shell and do ". ./+denv" in my git repository where
> that file has something like this:
> 
>         $ cat ./+denv
>         :
> 
>         GIT_EXEC_PATH=`pwd`
>         PATH=`pwd`:/usr/bin:/bin
> 
>         export GIT_EXEC_PATH PATH
> 
> So to a certain degree, yes I do care.

But it is currently broken:

xpasky@machine[0:0]~/git-pb$ rm -rf /home/xpasky/lib/perl5/
xpasky@machine[0:0]~/git-pb$ ./git-mv
Can't locate Git.pm in @INC (...)

(And I can't see any change that could aim to fix it.)

-- 
				Petr "Pasky" Baudis
Stuff: http://pasky.or.cz/
Snow falling on Perl. White noise covering line noise.
Hides all the bugs too. -- J. Putnam

Re: [POOL] Who likes running Git without make install?

[Junio C Hamano]

Petr Baudis <pasky@suse.cz> writes:

> Dear diary, on Sun, Jul 02, 2006 at 02:05:46AM CEST, I got a letter
> where Junio C Hamano <junkio@cox.net> said that...
>> That's fixed in ancient past in git timescale.  Why are you
>> bringing it up again? ;-)
>
> Because, it is, well, not fixed? ;-) (Apparently.)

That response is about "Worse yet, the order is wrong -- ah you
are right" exchange, not about in-place execution.

>> Well, for a quick test to see if I haven't broken anything, I
>> use a new shell and do ". ./+denv" in my git repository where
>> that file has something like this:
>> 
>>         $ cat ./+denv
>>         :
>> 
>>         GIT_EXEC_PATH=`pwd`
>>         PATH=`pwd`:/usr/bin:/bin
>> 
>>         export GIT_EXEC_PATH PATH
>> 
>> So to a certain degree, yes I do care.
>
> But it is currently broken:

I know.  The scriptlet needs to muck with PERL5LIB too.

Re: [POLL] Who likes running Git without make install?

[Junio C Hamano]

Petr Baudis <pasky@suse.cz> writes:

> Well, yes, it is ugly, but it was really cool that we could have used
> Git without installing it anywhere.
>
> But perhaps that's just me refusing to break his old ways of doing
> things. Does anyone else care about it? (And why?)

I do not think you need to break your old ways.  Perhaps a patch
like this might help.

-- >8 --
INSTALL: a tip for running after building but without installing.

Signed-off-by: Junio C Hamano <junkio@cox.net>
---
diff --git a/INSTALL b/INSTALL
index f8337e2..ed502de 100644
--- a/INSTALL
+++ b/INSTALL
@@ -29,6 +29,19 @@ Issues of note:
    has been actively developed since 1997, and people have moved over to
    graphical file managers.
 
+ - You can use git after building but without installing if you
+   wanted to.  Various git commands need to find other git
+   commands and scripts to do their work, so you would need to
+   arrange a few environment variables to tell them that their
+   friends will be found in your built source area instead of at
+   their standard installation area.  Something like this works
+   for me:
+
+	GIT_EXEC_PATH=`pwd`
+	PATH=`pwd`:$PATH
+	PERL5LIB=`pwd`/perl/blib/lib:`pwd`/perl/blib/arch/auto/Git
+	export GIT_EXEC_PATH PATH PERL5LIB
+
  - Git is reasonably self-sufficient, but does depend on a few external
    programs and libraries:
 

Re: [POLL] Who likes running Git without make install?

[Petr Baudis]

Dear diary, on Mon, Jul 03, 2006 at 08:54:47AM CEST, I got a letter
where Junio C Hamano <junkio@cox.net> said that...
> -- >8 --
> INSTALL: a tip for running after building but without installing.
> 
> Signed-off-by: Junio C Hamano <junkio@cox.net>

Acked-by: Petr Baudis <pasky@suse.cz>

I can live with this "weak (D3)". 99% of Git users probably use
installed Git instance anyway and most of the rest are likely to be Git
developers testing new code who can do this extra environment setup.

-- 
				Petr "Pasky" Baudis
Stuff: http://pasky.or.cz/
Snow falling on Perl. White noise covering line noise.
Hides all the bugs too. -- J. Putnam

Re: [POLL] Who likes running Git without make install?

[Junio C Hamano]

Petr Baudis <pasky@suse.cz> writes:

> Dear diary, on Mon, Jul 03, 2006 at 08:54:47AM CEST, I got a letter
> where Junio C Hamano <junkio@cox.net> said that...
>> -- >8 --
>> INSTALL: a tip for running after building but without installing.
>> 
>> Signed-off-by: Junio C Hamano <junkio@cox.net>
>
> Acked-by: Petr Baudis <pasky@suse.cz>
>
> I can live with this "weak (D3)". 99% of Git users probably use
> installed Git instance anyway and most of the rest are likely to be Git
> developers testing new code who can do this extra environment setup.

You earlier had to set two environment variables anyway but you
have added another.  I do not see what's weak about it.

Re: [POLL] Who likes running Git without make install?

[Petr Baudis]

Dear diary, on Mon, Jul 03, 2006 at 10:08:31AM CEST, I got a letter
where Junio C Hamano <junkio@cox.net> said that...
> Petr Baudis <pasky@suse.cz> writes:
> 
> > Dear diary, on Mon, Jul 03, 2006 at 08:54:47AM CEST, I got a letter
> > where Junio C Hamano <junkio@cox.net> said that...
> >> -- >8 --
> >> INSTALL: a tip for running after building but without installing.
> >> 
> >> Signed-off-by: Junio C Hamano <junkio@cox.net>
> >
> > Acked-by: Petr Baudis <pasky@suse.cz>
> >
> > I can live with this "weak (D3)". 99% of Git users probably use
> > installed Git instance anyway and most of the rest are likely to be Git
> > developers testing new code who can do this extra environment setup.
> 
> You earlier had to set two environment variables anyway but you
> have added another.  I do not see what's weak about it.

I don't usually use the git wrapper so I got away without setting
GIT_EXEC_PATH yet. ;-)

-- 
				Petr "Pasky" Baudis
Stuff: http://pasky.or.cz/
Snow falling on Perl. White noise covering line noise.
Hides all the bugs too. -- J. Putnam

Re: [POLL] Who likes running Git without make install?

[Johannes Schindelin]

Hi,

On Mon, 3 Jul 2006, Petr Baudis wrote:

> Dear diary, on Mon, Jul 03, 2006 at 10:08:31AM CEST, I got a letter
> where Junio C Hamano <junkio@cox.net> said that...
> > Petr Baudis <pasky@suse.cz> writes:
> > 
> > > Dear diary, on Mon, Jul 03, 2006 at 08:54:47AM CEST, I got a letter
> > > where Junio C Hamano <junkio@cox.net> said that...
> > >> -- >8 --
> > >> INSTALL: a tip for running after building but without installing.
> > >> 
> > >> Signed-off-by: Junio C Hamano <junkio@cox.net>
> > >
> > > Acked-by: Petr Baudis <pasky@suse.cz>
> > >
> > > I can live with this "weak (D3)". 99% of Git users probably use
> > > installed Git instance anyway and most of the rest are likely to be Git
> > > developers testing new code who can do this extra environment setup.
> > 
> > You earlier had to set two environment variables anyway but you
> > have added another.  I do not see what's weak about it.
> 
> I don't usually use the git wrapper so I got away without setting
> GIT_EXEC_PATH yet. ;-)

This is the config.mak I use everywhere:

-- snip --
bindir = $(shell pwd)
template_dir = $(bindir)/templates/blt
GIT_PYTHON_DIR = $(bindir)/compat
-- snap --

No environment variable.

Ciao,
Dscho