* [PATCH] optimized SHA1 for powerpc
From: Paul Mackerras @ 2005-04-22 5:52 UTC (permalink / raw)
To: torvalds; +Cc: git, anton
Linus,
Just for fun, I wrote a ppc-assembly SHA1 routine. It appears to be
about 2.5x faster than the generic version. It reduces the time for a
fsck-cache on a linux-2.6 tree from ~6.8 seconds to ~6.0 seconds on my
G4 powerbook.
Paul.
diff -urN git.orig/Makefile git/Makefile
--- git.orig/Makefile 2005-04-22 15:21:10.000000000 +1000
+++ git/Makefile 2005-04-22 15:11:28.000000000 +1000
@@ -25,7 +25,12 @@
LIB_OBJS=read-cache.o sha1_file.o usage.o object.o commit.o tree.o blob.o
LIB_FILE=libgit.a
-LIB_H=cache.h object.h
+LIB_H=cache.h object.h sha1.h
+
+arch := $(shell uname -m | tr -d 0-9)
+ifeq ($(arch),ppc)
+LIB_OBJS += sha1.o sha1ppc.o
+endif
$(LIB_FILE): $(LIB_OBJS)
$(AR) rcs $@ $(LIB_OBJS)
diff -urN git.orig/cache.h git/cache.h
--- git.orig/cache.h 2005-04-22 15:21:10.000000000 +1000
+++ git/cache.h 2005-04-22 13:57:36.000000000 +1000
@@ -12,7 +12,7 @@
#include <sys/mman.h>
#include <netinet/in.h>
-#include <openssl/sha.h>
+#include "sha1.h"
#include <zlib.h>
/*
diff -urN git.orig/sha1.c git/sha1.c
--- /dev/null 2005-04-04 12:56:19.000000000 +1000
+++ git/sha1.c 2005-04-22 15:17:27.000000000 +1000
@@ -0,0 +1,72 @@
+/*
+ * SHA-1 implementation.
+ *
+ * Copyright (C) 2005 Paul Mackerras <paulus@samba.org>
+ *
+ * This version assumes we are running on a big-endian machine.
+ * It calls an external sha1_core() to process blocks of 64 bytes.
+ */
+#include <stdio.h>
+#include <string.h>
+#include "sha1.h"
+
+extern void sha1_core(uint32_t *hash, const unsigned char *p,
+ unsigned int nblocks);
+
+int SHA1_Init(SHA_CTX *c)
+{
+ c->hash[0] = 0x67452301;
+ c->hash[1] = 0xEFCDAB89;
+ c->hash[2] = 0x98BADCFE;
+ c->hash[3] = 0x10325476;
+ c->hash[4] = 0xC3D2E1F0;
+ c->len = 0;
+ c->cnt = 0;
+ return 0;
+}
+
+int SHA1_Update(SHA_CTX *c, const void *ptr, unsigned long n)
+{
+ unsigned long nb;
+ const unsigned char *p = ptr;
+
+ c->len += n << 3;
+ while (n != 0) {
+ if (c->cnt || n < 64) {
+ nb = 64 - c->cnt;
+ if (nb > n)
+ nb = n;
+ memcpy(&c->buf.b[c->cnt], p, nb);
+ if ((c->cnt += nb) == 64) {
+ sha1_core(c->hash, c->buf.b, 1);
+ c->cnt = 0;
+ }
+ } else {
+ nb = n >> 6;
+ sha1_core(c->hash, p, nb);
+ nb <<= 6;
+ }
+ n -= nb;
+ p += nb;
+ }
+ return 0;
+}
+
+int SHA1_Final(unsigned char *hash, SHA_CTX *c)
+{
+ unsigned int cnt = c->cnt;
+
+ c->buf.b[cnt++] = 0x80;
+ if (cnt > 56) {
+ if (cnt < 64)
+ memset(&c->buf.b[cnt], 0, 64 - cnt);
+ sha1_core(c->hash, c->buf.b, 1);
+ cnt = 0;
+ }
+ if (cnt < 56)
+ memset(&c->buf.b[cnt], 0, 56 - cnt);
+ c->buf.l[7] = c->len;
+ sha1_core(c->hash, c->buf.b, 1);
+ memcpy(hash, c->hash, 20);
+ return 0;
+}
diff -urN git.orig/sha1.h git/sha1.h
--- /dev/null 2005-04-04 12:56:19.000000000 +1000
+++ git/sha1.h 2005-04-22 15:06:53.000000000 +1000
@@ -0,0 +1,19 @@
+#ifndef __powerpc__
+#include <openssl/sha.h>
+#else
+#include <stdint.h>
+
+typedef struct sha_context {
+ uint32_t hash[5];
+ uint32_t cnt;
+ uint64_t len;
+ union {
+ unsigned char b[64];
+ uint64_t l[8];
+ } buf;
+} SHA_CTX;
+
+int SHA1_Init(SHA_CTX *c);
+int SHA1_Update(SHA_CTX *c, const void *p, unsigned long n);
+int SHA1_Final(unsigned char *hash, SHA_CTX *c);
+#endif
diff -urN git.orig/sha1ppc.S git/sha1ppc.S
--- /dev/null 2005-04-04 12:56:19.000000000 +1000
+++ git/sha1ppc.S 2005-04-22 15:18:19.000000000 +1000
@@ -0,0 +1,185 @@
+/*
+ * SHA-1 implementation for PowerPC.
+ *
+ * Copyright (C) 2005 Paul Mackerras.
+ */
+#define FS 80
+
+/*
+ * We roll the registers for T, A, B, C, D, E around on each
+ * iteration; T on iteration t is A on iteration t+1, and so on.
+ * We use registers 7 - 12 for this.
+ */
+#define RT(t) ((((t)+5)%6)+7)
+#define RA(t) ((((t)+4)%6)+7)
+#define RB(t) ((((t)+3)%6)+7)
+#define RC(t) ((((t)+2)%6)+7)
+#define RD(t) ((((t)+1)%6)+7)
+#define RE(t) ((((t)+0)%6)+7)
+
+/* We use registers 16 - 31 for the W values */
+#define W(t) (((t)%16)+16)
+
+#define STEPD0(t) \
+ and %r6,RB(t),RC(t); \
+ andc %r0,RD(t),RB(t); \
+ rotlwi RT(t),RA(t),5; \
+ rotlwi RB(t),RB(t),30; \
+ or %r6,%r6,%r0; \
+ add %r0,RE(t),%r15; \
+ add RT(t),RT(t),%r6; \
+ add %r0,%r0,W(t); \
+ add RT(t),RT(t),%r0
+
+#define STEPD1(t) \
+ xor %r6,RB(t),RC(t); \
+ rotlwi RT(t),RA(t),5; \
+ rotlwi RB(t),RB(t),30; \
+ xor %r6,%r6,RD(t); \
+ add %r0,RE(t),%r15; \
+ add RT(t),RT(t),%r6; \
+ add %r0,%r0,W(t); \
+ add RT(t),RT(t),%r0
+
+#define STEPD2(t) \
+ and %r6,RB(t),RC(t); \
+ and %r0,RB(t),RD(t); \
+ rotlwi RT(t),RA(t),5; \
+ rotlwi RB(t),RB(t),30; \
+ or %r6,%r6,%r0; \
+ and %r0,RC(t),RD(t); \
+ or %r6,%r6,%r0; \
+ add %r0,RE(t),%r15; \
+ add RT(t),RT(t),%r6; \
+ add %r0,%r0,W(t); \
+ add RT(t),RT(t),%r0
+
+#define LOADW(t) \
+ lwz W(t),(t)*4(%r4)
+
+#define UPDATEW(t) \
+ xor %r0,W((t)-3),W((t)-8); \
+ xor W(t),W((t)-16),W((t)-14); \
+ xor W(t),W(t),%r0; \
+ rotlwi W(t),W(t),1
+
+#define STEP0LD4(t) \
+ STEPD0(t); LOADW((t)+4); \
+ STEPD0((t)+1); LOADW((t)+5); \
+ STEPD0((t)+2); LOADW((t)+6); \
+ STEPD0((t)+3); LOADW((t)+7)
+
+#define STEPUP4(t, fn) \
+ STEP##fn(t); UPDATEW((t)+4); \
+ STEP##fn((t)+1); UPDATEW((t)+5); \
+ STEP##fn((t)+2); UPDATEW((t)+6); \
+ STEP##fn((t)+3); UPDATEW((t)+7)
+
+#define STEPUP20(t, fn) \
+ STEPUP4(t, fn); \
+ STEPUP4((t)+4, fn); \
+ STEPUP4((t)+8, fn); \
+ STEPUP4((t)+12, fn); \
+ STEPUP4((t)+16, fn)
+
+ .globl sha1_core
+sha1_core:
+ stwu %r1,-FS(%r1)
+ stw %r15,FS-68(%r1)
+ stw %r16,FS-64(%r1)
+ stw %r17,FS-60(%r1)
+ stw %r18,FS-56(%r1)
+ stw %r19,FS-52(%r1)
+ stw %r20,FS-48(%r1)
+ stw %r21,FS-44(%r1)
+ stw %r22,FS-40(%r1)
+ stw %r23,FS-36(%r1)
+ stw %r24,FS-32(%r1)
+ stw %r25,FS-28(%r1)
+ stw %r26,FS-24(%r1)
+ stw %r27,FS-20(%r1)
+ stw %r28,FS-16(%r1)
+ stw %r29,FS-12(%r1)
+ stw %r30,FS-8(%r1)
+ stw %r31,FS-4(%r1)
+
+ /* Load up A - E */
+ lwz RA(0),0(%r3) /* A */
+ lwz RB(0),4(%r3) /* B */
+ lwz RC(0),8(%r3) /* C */
+ lwz RD(0),12(%r3) /* D */
+ lwz RE(0),16(%r3) /* E */
+
+ mtctr %r5
+
+1: LOADW(0)
+ LOADW(1)
+ LOADW(2)
+ LOADW(3)
+
+ lis %r15,0x5a82 /* K0-19 */
+ ori %r15,%r15,0x7999
+ STEP0LD4(0)
+ STEP0LD4(4)
+ STEP0LD4(8)
+ STEPUP4(12, D0)
+ STEPUP4(16, D0)
+
+ lis %r15,0x6ed9 /* K20-39 */
+ ori %r15,%r15,0xeba1
+ STEPUP20(20, D1)
+
+ lis %r15,0x8f1b /* K40-59 */
+ ori %r15,%r15,0xbcdc
+ STEPUP20(40, D2)
+
+ lis %r15,0xca62 /* K60-79 */
+ ori %r15,%r15,0xc1d6
+ STEPUP4(60, D1)
+ STEPUP4(64, D1)
+ STEPUP4(68, D1)
+ STEPUP4(72, D1)
+ STEPD1(76)
+ STEPD1(77)
+ STEPD1(78)
+ STEPD1(79)
+
+ lwz %r20,16(%r3)
+ lwz %r19,12(%r3)
+ lwz %r18,8(%r3)
+ lwz %r17,4(%r3)
+ lwz %r16,0(%r3)
+ add %r20,RE(80),%r20
+ add RD(0),RD(80),%r19
+ add RC(0),RC(80),%r18
+ add RB(0),RB(80),%r17
+ add RA(0),RA(80),%r16
+ mr RE(0),%r20
+ stw RA(0),0(%r3)
+ stw RB(0),4(%r3)
+ stw RC(0),8(%r3)
+ stw RD(0),12(%r3)
+ stw RE(0),16(%r3)
+
+ addi %r4,%r4,64
+ bdnz 1b
+
+ lwz %r15,FS-68(%r1)
+ lwz %r16,FS-64(%r1)
+ lwz %r17,FS-60(%r1)
+ lwz %r18,FS-56(%r1)
+ lwz %r19,FS-52(%r1)
+ lwz %r20,FS-48(%r1)
+ lwz %r21,FS-44(%r1)
+ lwz %r22,FS-40(%r1)
+ lwz %r23,FS-36(%r1)
+ lwz %r24,FS-32(%r1)
+ lwz %r25,FS-28(%r1)
+ lwz %r26,FS-24(%r1)
+ lwz %r27,FS-20(%r1)
+ lwz %r28,FS-16(%r1)
+ lwz %r29,FS-12(%r1)
+ lwz %r30,FS-8(%r1)
+ lwz %r31,FS-4(%r1)
+ addi %r1,%r1,FS
+ blr
^ permalink raw reply
* Re: "GIT_INDEX_FILE" environment variable
From: Linus Torvalds @ 2005-04-22 5:05 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Git Mailing List
In-Reply-To: <7vis2fbr0p.fsf@assigned-by-dhcp.cox.net>
On Thu, 21 Apr 2005, Junio C Hamano wrote:
>
> I am thinking about an alternative way of doing the above by
> some modifications to the git core. I think the root of this
> problem is that there is no equivalent to GIT_INDEX_FILE and
> SHA1_FILE_DIRECTORY that tells the core git where the project
> top directory (i.e. the root of the working tree that
> corresponds to what $GIT_INDEX_FILE describes) is.
I'd _really_ prefer to just try to teach people to work from the "top"
directory instead.
> - A new environment variable GIT_WORKING_TREE points at the
> root of the working tree.
>
> - Each git core command [*1*] that looks at the working tree is
> modified to take the user supplied pathname as a path
> relative to the current working directory, and use
> GIT_WORKING_TREE value to figure out which path the user is
> talking about, relative to the tree structure GIT_INDEX_FILE
> describes.
I really don't like it that much, but to some degree it obviously is
exactly what "--prefix=" does to checkout-cache. It's basically saying
that all normal file operations have to be prefixed with a magic string.
And git really doesn't do too many of those, so maybe it's ok. What would
the patch look like? I don't really love the idea, but if the patch is
clean enough...
Linus
^ permalink raw reply
* Re: [ANNOUNCE] git-pasky-0.6.3 && request for testing
From: Steven Cole @ 2005-04-22 3:58 UTC (permalink / raw)
To: Petr Baudis; +Cc: git
In-Reply-To: <20050422030931.GA14565@pasky.ji.cz>
On Thursday 21 April 2005 09:09 pm, Petr Baudis wrote:
> Hello,
>
> FYI, I've released git-pasky-0.6.3 earlier in the night. It brings
> especially plenty of bugfixes, but also some tiny enhancements, like
> colored log and ability to pick branch in the remote repository. git log
> and git patch now also accept range of commits, so e.g. if you do
Here's a patch to let people know about the nice color feature.
Signed-off-by: Steven Cole <elenstev@mesatop.com>
Index: git
===================================================================
--- 0a9ee5a4d947b998a7ce489242800b39f98eeee5/git (mode:100755 sha1:39969debd59ed51c57973c819cdcc3ca8a7da819)
+++ uncommitted/git (mode:100755)
@@ -35,7 +35,7 @@
fork BNAME BRANCH_DIR [COMMIT_ID]
help
init RSYNC_URL
- log [COMMIT_ID | COMMIT_ID:COMMIT_ID]
+ log [-c] [COMMIT_ID | COMMIT_ID:COMMIT_ID]
ls [TREE_ID]
lsobj [OBJTYPE]
lsremote
Index: gitlog.sh
===================================================================
--- 0a9ee5a4d947b998a7ce489242800b39f98eeee5/gitlog.sh (mode:100755 sha1:50eab642cdf5e695cf15be4ce3a7469dd68637e7)
+++ uncommitted/gitlog.sh (mode:100755)
@@ -7,6 +7,14 @@
# Major optimizations by (c) Phillip Lougher.
# Rendered trivial by Linus Torvalds.
#
+# Takes a -c option to add color to the output.
+# Currently, the colors are:
+#
+# header Green
+# author Cyan
+# committer Magenta
+# signoff Yellow
+#
# Takes an id resolving to a commit to start from (HEAD by default),
# or id1:id2 representing an (id1;id2] range of commits to show.
^ permalink raw reply
* Re: ia64 git pull
From: David A. Wheeler @ 2005-04-22 3:30 UTC (permalink / raw)
To: Inaky Perez-Gonzalez
Cc: Petr Baudis, tony.luck, Linus Torvalds, linux-ia64, linux-kernel,
git
In-Reply-To: <17000.23588.462823.574142@sodium.jf.intel.com>
Petr Baudis <pasky@ucw.cz> writes:
>>Still, why would you escape it? My shell will not take # as a
>>comment start if it is immediately after an alphanumeric character.
I guess there MIGHT be some command shell implementation
that stupidly _DID_ accept "#" as a comment character,
even immediately after an alphanumeric.
If that's true, then using # there would be a pain for portability.
But I think that's highly improbable. A quick peek
at the Single Unix Specification as posted by the Open Group
seems to say that, according to the standards, that's NOT okay:
http://www.opengroup.org/onlinepubs/009695399/utilities/xcu_chap02.html#tag_02
Basically, the command shell is supposed to tokenize, and "#"
only means comment if it's at the beginning of a token.
And as far as I can tell, it's not an issue in practice either.
I did a few quick tests on Fedora Core 3 and OpenBSD.
On Fedora Core 3, I can say that bash, ash & csh all do NOT
consider "#" as a comment start if an alpha precedes it.
The same is true for OpenBSD /bin/sh, /bin/csh, and /bin/rksh.
If such different shells do the same thing (this stuff isn't even
legal C-shell text!), it's likely others do too.
--- David A. Wheeler
^ permalink raw reply
* [PATCH] Eliminate use of mktemp's "-t" option
From: David A. Wheeler @ 2005-04-22 3:13 UTC (permalink / raw)
To: Petr Baudis; +Cc: git
In-Reply-To: <20050422024010.GE7443@pasky.ji.cz>
[-- Attachment #1: Type: text/plain, Size: 551 bytes --]
It turns out that mktemp's "-t" option, while useful, isn't
available on many systems (Mandrake & Red Hat Linux 9 at least,
and probably piles of others). So, here's a portability
patch that removes all use of mktemp's "-t" option.
Unlike the quick hack I posted earlier, this should be
"clean everywhere" (assuming you have mktemp).
This is a patch against git-pasky 0.6.3.
This is my first attempt to _post_ a patch using git itself,
and I'm not entirely sure how you want it. Let me know
if you have a problem with it!
--- David A. Wheeler
[-- Attachment #2: rm-mktemp-dash-t.patch --]
[-- Type: text/plain, Size: 4612 bytes --]
commit 5f926b684025b83e34386bf8e4ef30a97e2ae5ec
tree 61059575269ed1027cfb66543251e182f87d1064
parent dd69ca5f806c8b10bb29ecb8d77c88be007c981c
author David A. Wheeler <dwheeler@dwheeler.com> 1114138972 -0400
committer David A. Wheeler <dwheeler@dwheeler.com> 1114138972 -0400
Eliminated use of mktemp's "-t" option; older mktemps don't support it.
Index: README
===================================================================
--- 6a612d42afdba20fd2150e319a689ed451b010e4/README (mode:100644 sha1:a71b5fbdbdac0bf2e2d021e422b9f49dd5481165)
+++ 61059575269ed1027cfb66543251e182f87d1064/README (mode:100644 sha1:80952e2f67b28f64c10cfb913df375a5dd244cd9)
@@ -141,7 +141,7 @@
C compiler
bash
basic shell environment (sed, grep, textutils, ...)
- mktemp 1.5+ (Mandrake users beware!)
+ mktemp
diff, patch
libssl
rsync
Index: gitapply.sh
===================================================================
--- 6a612d42afdba20fd2150e319a689ed451b010e4/gitapply.sh (mode:100755 sha1:7703809dc0743c6e4c1fa5b7d922a4efc16b4276)
+++ 61059575269ed1027cfb66543251e182f87d1064/gitapply.sh (mode:100755 sha1:14a13ff23cff2a80f9a44c053002f837fec13e2c)
@@ -8,9 +8,13 @@
#
# Takes the diff on stdin.
-gonefile=$(mktemp -t gitapply.XXXXXX)
-todo=$(mktemp -t gitapply.XXXXXX)
-patchfifo=$(mktemp -t gitapply.XXXXXX)
+if [ -z "$TMPDIR"]; then
+ TMPDIR=/tmp
+fi
+
+gonefile=$(mktemp "$TMPDIR/gitapply.XXXXXX")
+todo=$(mktemp "$TMPDIR/gitapply.XXXXXX")
+patchfifo=$(mktemp "$TMPDIR/gitapply.XXXXXX")
rm $patchfifo && mkfifo -m 600 $patchfifo
show-files --deleted >$gonefile
Index: gitcommit.sh
===================================================================
--- 6a612d42afdba20fd2150e319a689ed451b010e4/gitcommit.sh (mode:100755 sha1:a13bef2c84492ed75679d7d52bb710df35544f8a)
+++ 61059575269ed1027cfb66543251e182f87d1064/gitcommit.sh (mode:100755 sha1:ee777605dccdc9737cf743f4f8c96b9bacd97f10)
@@ -16,6 +16,9 @@
exit 1
}
+if [ -z "$TMPDIR"]; then
+ TMPDIR=/tmp
+fi
[ -s .git/blocked ] && die "committing blocked: $(cat .git/blocked)"
@@ -67,7 +70,7 @@
fi
echo "Enter commit message, terminated by ctrl-D on a separate line:"
-LOGMSG=$(mktemp -t gitci.XXXXXX)
+LOGMSG=$(mktemp "$TMPDIR/gitci.XXXXXX")
if [ "$merging" ]; then
echo -n 'Merge with ' >>$LOGMSG
echo -n 'Merge with '
@@ -111,7 +114,7 @@
if [ ! "$customfiles" ]; then
rm -f .git/add-queue .git/rm-queue
else
- greptmp=$(mktemp -t gitci.XXXXXX)
+ greptmp=$(mktemp "$TMPDIR/gitci.XXXXXX")
for file in $customfiles; do
if [ -s .git/add-queue ]; then
fgrep -vx "$file" .git/add-queue >$greptmp
Index: gitdiff-do
===================================================================
--- 6a612d42afdba20fd2150e319a689ed451b010e4/gitdiff-do (mode:100755 sha1:218dfabeb4a5dcbd2cf58bd6f672f385690ec397)
+++ 61059575269ed1027cfb66543251e182f87d1064/gitdiff-do (mode:100755 sha1:caf20ae034b8dc9f88922ee9f82809bb32a56231)
@@ -32,7 +32,11 @@
[ "$labelapp" ] && label="$label ($labelapp)"
}
-diffdir=$(mktemp -d -t gitdiff.XXXXXX)
+if [ -z "$TMPDIR"]; then
+ TMPDIR=/tmp
+fi
+
+diffdir=$(mktemp -d "$TMPDIR/gitdiff.XXXXXX")
diffdir1="$diffdir/$id1"
diffdir2="$diffdir/$id2"
mkdir "$diffdir1" "$diffdir2"
Index: gitdiff.sh
===================================================================
--- 6a612d42afdba20fd2150e319a689ed451b010e4/gitdiff.sh (mode:100755 sha1:195c3b9962c764855ec6168a78babf5867ea3046)
+++ 61059575269ed1027cfb66543251e182f87d1064/gitdiff.sh (mode:100755 sha1:278511a3f491ed7d5e41bbd642acfd9b5a1d8257)
@@ -80,6 +80,10 @@
shift
fi
+if [ -z "$TMPDIR"]; then
+ TMPDIR=/tmp
+fi
+
if [ "$parent" ]; then
id2="$id1"
id1=$(parent-id "$id2" | head -n 1)
@@ -88,7 +92,7 @@
if [ "$id2" = " " ]; then
if [ "$id1" != " " ]; then
- export GIT_INDEX_FILE=$(mktemp -t gitdiff.XXXXXX)
+ export GIT_INDEX_FILE=$(mktemp "$TMPDIR/gitdiff.XXXXXX")
read-tree $(gitXnormid.sh "$id1")
update-cache --refresh
fi
Index: gitmerge.sh
===================================================================
--- 6a612d42afdba20fd2150e319a689ed451b010e4/gitmerge.sh (mode:100755 sha1:683755729b6f689ea43c692712fad6e51eeac354)
+++ 61059575269ed1027cfb66543251e182f87d1064/gitmerge.sh (mode:100755 sha1:1c733bbdb9fe54c41787d962d0f55bb5f67d4c63)
@@ -19,6 +19,10 @@
exit 1
}
+if [ -z "$TMPDIR"]; then
+ TMPDIR=/tmp
+fi
+
head=$(commit-id)
@@ -58,7 +62,7 @@
echo "Fast-forwarding $base -> $branch" >&2
echo -e "\ton top of $head..." >&2
- patchfile=$(mktemp -t gitmerge.XXXXXX)
+ patchfile=$(mktemp "$TMPDIR/gitmerge.XXXXXX")
gitdiff.sh >$patchfile
read-tree -m $(tree-id $branch)
^ permalink raw reply
* [ANNOUNCE] git-pasky-0.6.3 && request for testing
From: Petr Baudis @ 2005-04-22 3:09 UTC (permalink / raw)
To: git
Hello,
FYI, I've released git-pasky-0.6.3 earlier in the night. It brings
especially plenty of bugfixes, but also some tiny enhancements, like
colored log and ability to pick branch in the remote repository. git log
and git patch now also accept range of commits, so e.g. if you do
git patch linus:this
you should get a sequence of patches (commit message + patch, with
delimiters between patches) which will bring you from linus to your
current HEAD. Of course the package is in sync with Linus' branch.
Get it at
http://pasky.or.cz/~pasky/dev/git/
or pull (it should work fine, no format changes).
Not released stay changes I made later tonight, which change
git-pasky's usage of directory cache - it will record adds/removals to
it and use diff-cache instead of show-diff to check any differences. The
code is much simpler, but likely some small bugs were introduced in the
process - please report any problems you'll hit, and test heavily. What
is known is that you cannot diff specific files now.
Thanks,
--
Petr "Pasky" Baudis
Stuff: http://pasky.or.cz/
C++: an octopus made by nailing extra legs onto a dog. -- Steve Taylor
^ permalink raw reply
* Re: [PATCH] git-pasky spec file
From: Chris Wright @ 2005-04-22 2:48 UTC (permalink / raw)
To: Petr Baudis; +Cc: Chris Wright, git
In-Reply-To: <20050422024010.GE7443@pasky.ji.cz>
* Petr Baudis (pasky@ucw.cz) wrote:
> Dear diary, on Fri, Apr 22, 2005 at 03:55:21AM CEST, I got a letter
> where Chris Wright <chrisw@osdl.org> told me that...
> > Here's a simple spec file to do rpm builds. It's against the
> > latest Makefile (which has the s/BINDIR/bindir/ change). I've used
> > DESTDIR, although it's not clear it's meant to stay in the Makefile.
> > For now, there's no dynamic (git.spec.in, for example) update to the
> > Version, so it's set against 0.6.3 (expecting it to be forthcoming
> > shortly). It installs to /usr/local/bin, and expects the tarball to be
> > named git-pasky-0.6.3.tar.bz2. Creates a package named git, which seems
> > fine since Linus' isn't likely to be packaged directly. Enjoy.
>
> Thanks, applied. I'll gladly yet you maintain this file, but...
No problem...
> > --- /dev/null 1969-12-31 16:00:00.000000000 -0800
> > +++ git-pasky-0.6.3/git.spec 2005-04-21 18:42:18.000000000 -0700
> > @@ -0,0 +1,43 @@
> > +%install
> > +rm -rf $RPM_BUILD_ROOT
> > +make DESTDIR=$RPM_BUILD_ROOT/usr/local/ bindir=bin/ install
>
> I doubt this is actually what you want. I suppose you want
>
> make DESTDIR=$RPM_BUILD_ROOT prefix=/usr/local install
Yup, that makes more sense. Feel free to update if you're so inclined.
thanks,
-chris
--
Linux Security Modules http://lsm.immunix.org http://lsm.bkbits.net
^ permalink raw reply
* Re: [PATCH] git-pasky spec file
From: Petr Baudis @ 2005-04-22 2:40 UTC (permalink / raw)
To: Chris Wright; +Cc: git
In-Reply-To: <20050422015521.GK493@shell0.pdx.osdl.net>
Dear diary, on Fri, Apr 22, 2005 at 03:55:21AM CEST, I got a letter
where Chris Wright <chrisw@osdl.org> told me that...
> Here's a simple spec file to do rpm builds. It's against the
> latest Makefile (which has the s/BINDIR/bindir/ change). I've used
> DESTDIR, although it's not clear it's meant to stay in the Makefile.
> For now, there's no dynamic (git.spec.in, for example) update to the
> Version, so it's set against 0.6.3 (expecting it to be forthcoming
> shortly). It installs to /usr/local/bin, and expects the tarball to be
> named git-pasky-0.6.3.tar.bz2. Creates a package named git, which seems
> fine since Linus' isn't likely to be packaged directly. Enjoy.
Thanks, applied. I'll gladly yet you maintain this file, but...
> --- /dev/null 1969-12-31 16:00:00.000000000 -0800
> +++ git-pasky-0.6.3/git.spec 2005-04-21 18:42:18.000000000 -0700
> @@ -0,0 +1,43 @@
> +%install
> +rm -rf $RPM_BUILD_ROOT
> +make DESTDIR=$RPM_BUILD_ROOT/usr/local/ bindir=bin/ install
I doubt this is actually what you want. I suppose you want
make DESTDIR=$RPM_BUILD_ROOT prefix=/usr/local install
instead. This may not matter now, but might well in future when we stuff
some of the helper/library scripts to some lib/ or share/ directory, and
will actually rewrite some paths somewhere based on $prefix during make
install.
--
Petr "Pasky" Baudis
Stuff: http://pasky.or.cz/
C++: an octopus made by nailing extra legs onto a dog. -- Steve Taylor
^ permalink raw reply
* Re: ia64 git pull
From: Inaky Perez-Gonzalez @ 2005-04-22 2:06 UTC (permalink / raw)
To: Petr Baudis; +Cc: tony.luck, Linus Torvalds, linux-ia64, linux-kernel, git
In-Reply-To: <20050422015340.GD7443@pasky.ji.cz>
>>>>> Petr Baudis <pasky@ucw.cz> writes:
> Remember that it's an URL (so you can't use '%'), and '#' is the
> canonical URL fragment identifier delimiter. (And fragments are
> perfect for this kind of thing, if you look at the RFC, BTW.)
Ouch, true--rule out %...
> Still, why would you escape it? My shell will not take # as a
> comment start if it is immediately after an alphanumeric character.
Well, you just taught me something about bash I didn't know....
/me goes back to his hole with some more knowledge.
Thanks,
--
Inaky
^ permalink raw reply
* [PATCH] git-pasky spec file
From: Chris Wright @ 2005-04-22 1:55 UTC (permalink / raw)
To: Petr Baudis; +Cc: git
Here's a simple spec file to do rpm builds. It's against the
latest Makefile (which has the s/BINDIR/bindir/ change). I've used
DESTDIR, although it's not clear it's meant to stay in the Makefile.
For now, there's no dynamic (git.spec.in, for example) update to the
Version, so it's set against 0.6.3 (expecting it to be forthcoming
shortly). It installs to /usr/local/bin, and expects the tarball to be
named git-pasky-0.6.3.tar.bz2. Creates a package named git, which seems
fine since Linus' isn't likely to be packaged directly. Enjoy.
Signed-off-by: Chris Wright <chrisw@osdl.org>
--- /dev/null 1969-12-31 16:00:00.000000000 -0800
+++ git-pasky-0.6.3/git.spec 2005-04-21 18:42:18.000000000 -0700
@@ -0,0 +1,43 @@
+Name: git
+Version: 0.6.3
+Release: 1
+Vendor: Petr Baudis <pasky@ucw.cz>
+Summary: Git core and tools
+License: GPL
+Group: Development/Tools
+URL: http://pasky.or.cz/~pasky/dev/git/
+Source: http://pasky.or.cz/~pasky/dev/git/%{name}-pasky-%{version}.tar.bz2
+Provides: git = %{version}
+BuildRequires: zlib-devel openssl-devel
+BuildRoot: %{_tmppath}/%{name}-%{version}-root
+Prereq: sh-utils diffutils
+
+%description
+GIT comes in two layers. The bottom layer is merely an extremely fast
+and flexible filesystem-based database designed to store directory trees
+with regard to their history. The top layer is a SCM-like tool which
+enables human beings to work with the database in a manner to a degree
+similar to other SCM tools (like CVS, BitKeeper or Monotone).
+
+%prep
+%setup -q -n %{name}-pasky-%{version}
+
+%build
+
+make
+
+%install
+rm -rf $RPM_BUILD_ROOT
+make DESTDIR=$RPM_BUILD_ROOT/usr/local/ bindir=bin/ install
+
+%clean
+rm -rf $RPM_BUILD_ROOT
+
+%files
+%defattr(-,root,root)
+/usr/local/bin/*
+#%{_mandir}/*/*
+
+%changelog
+* Thu Apr 21 2005 Chris Wright <chrisw@osdl.org> 0.6.3-1
+- Initial rpm build
^ permalink raw reply
* Re: ia64 git pull
From: Petr Baudis @ 2005-04-22 1:53 UTC (permalink / raw)
To: Inaky Perez-Gonzalez
Cc: tony.luck, Linus Torvalds, linux-ia64, linux-kernel, git
In-Reply-To: <17000.22515.170455.192374@sodium.jf.intel.com>
Dear diary, on Fri, Apr 22, 2005 at 03:48:35AM CEST, I got a letter
where Inaky Perez-Gonzalez <inaky@linux.intel.com> told me that...
> >>>>> Petr Baudis <pasky@ucw.cz> writes:
>
> > I've just added to git-pasky a possibility to refer to branches
> > inside of repositories by a fragment identifier:
>
> > rsync://rsync.kernel.org/pub/scm/linux/kernel/git/aegl/linux-2.6.git#testing
>
> > will refer to your testing branch in that repository.
>
> Can we use something other than #? we'll have to scape it all the time
> in the shell (or at least also allow some other char, something
> without special meta-character meaning in the shell, like %).
Remember that it's an URL (so you can't use '%'), and '#' is the
canonical URL fragment identifier delimiter. (And fragments are perfect
for this kind of thing, if you look at the RFC, BTW.)
Still, why would you escape it? My shell will not take # as a comment
start if it is immediately after an alphanumeric character.
--
Petr "Pasky" Baudis
Stuff: http://pasky.or.cz/
C++: an octopus made by nailing extra legs onto a dog. -- Steve Taylor
^ permalink raw reply
* [PATCH] Colored log on any ANSI capable terminal
From: Pavel Roskin @ 2005-04-22 1:42 UTC (permalink / raw)
To: git
Hello!
setterm only works on Linux terminal. It should be safe to use raw ANSI
sequences -they work on most terminals, including xterm. Nobody forces
you to use the "-c" option to "git log" on those stone-age terminals
that neither support nor ignore ANSI color codes.
I'm aware of $'...' but it may not work in bash 1.x.
Signed-off-by: Pavel Roskin <proski@gnu.org>
--- a/gitlog.sh
+++ b/gitlog.sh
@@ -12,11 +12,11 @@
if [ "$1" = "-c" ]; then
shift
- colheader=$(setterm -foreground green)
- colauthor=$(setterm -foreground cyan)
- colcommitter=$(setterm -foreground magenta)
- colsignoff=$(setterm -foreground yellow)
- coldefault=$(setterm -foreground default)
+ colheader=$(echo -ne '\e[32m')
+ colauthor=$(echo -ne '\e[36m')
+ colcommitter=$(echo -ne '\e[35m')
+ colsignoff=$(echo -ne '\e[33m')
+ coldefault=$(echo -ne '\e[39m')
else
colheader=
colauthor=
--
Regards,
Pavel Roskin
^ permalink raw reply
* Re: [PATCH] Colorized git log
From: Steven Cole @ 2005-04-22 1:04 UTC (permalink / raw)
To: Petr Baudis; +Cc: Daniel Serpell, GIT Mailing Lists
In-Reply-To: <20050422005452.GZ7443@pasky.ji.cz>
On Thursday 21 April 2005 06:54 pm, Petr Baudis wrote:
> Duh. And they say "Where possible terminfo is consulted to find the
> string to use." in their manual page. :/
>
> > gitlog.sh: 6d24d857fb6c2f7e810954adaca1990599906f07
> > --- a/gitlog.sh
> > +++ b/gitlog.sh
> > @@ -11,11 +11,11 @@
> >
> > if [ "$1" = "-c" ]; then
> > shift
> > - colheader=$(setterm -foreground green)
> > - colauthor=$(setterm -foreground cyan)
> > - colcommitter=$(setterm -foreground magenta)
> > - colsignoff=$(setterm -foreground yellow)
> > - coldefault=$(setterm -foreground default)
> > + colheader="$(tput setaf 2)"
> > + colauthor="$(tput setaf 6)"
> > + colcommitter="$(tput setaf 5)"
> > + colsignoff="$(tput setaf 3)"
> > + coldefault="$(tput op)"
> > else
> > colheader=
> > colauthor=
>
> Please at least stick the colors in comments after the assignment.
> Not everyone knows ANSI color codes off-hand (the last thing I've
> memorized were BIOS color codes in the distant DOS days).
>
I like the color idea, but since many people have their own idea
of what colors are appropriate, etc (I use a dark background, and
the magenta is painful), perhaps we could have a LOG_COLORS
file, similar in concept (but more readable) to the /etc/DIR_COLORS
file. Great work !
Steven
^ permalink raw reply
* Re: [PATCH] Colorized git log
From: Daniel Serpell @ 2005-04-22 1:04 UTC (permalink / raw)
To: GIT Mailing Lists; +Cc: Petr Baudis
In-Reply-To: <20050422005452.GZ7443@pasky.ji.cz>
Hi!
On 4/21/05, Petr Baudis <pasky@ucw.cz> wrote:
> Dear diary, on Fri, Apr 22, 2005 at 02:46:19AM CEST, I got a letter
> where Daniel Serpell <daniel.serpell@gmail.com> told me that...
> >
> > This has two problems, solved in two patches:
>
> could you please sign them off?
Ok, here are, resent (I suppose it's ok tho put all in one e-mail),
and with the comments added.
--------------
Strip space in front of colorized header lines.
Signed-off-by: Daniel Serpell <daniel.serpell@gmail.com>
+++ b/gitlog.sh
@@ -27,7 +27,7 @@ fi
base=$(gitXnormid.sh -c $1) || exit 1
rev-tree $base | sort -rn | while read time commit parents; do
- echo $colheader commit ${commit%:*} $coldefault;
+ echo $colheader""commit ${commit%:*} $coldefault;
cat-file commit $commit | \
while read key rest; do
case "$key" in
@@ -43,10 +43,10 @@ rev-tree $base | sort -rn | while read t
dtz=${tz/+/+ }; dtz=${dtz/-/- }
pdate="$(date -Rud "1970-01-01 UTC + $sec sec $dtz" 2>/dev/null)"
if [ "$pdate" ]; then
- echo -n $color $key $rest | sed "s/>.*/> ${pdate/+0000/$tz}/"
+ echo -n $color$key $rest | sed "s/>.*/> ${pdate/+0000/$tz}/"
echo $coldefault
else
- echo $color $key $rest $coldefault
+ echo $color$key $rest $coldefault
fi
;;
"")
@@ -56,7 +56,7 @@ rev-tree $base | sort -rn | while read t
'
;;
*)
- echo $colheader $key $rest $coldefault
+ echo $colheader$key $rest $coldefault
;;
esac
--------------
Uses tput instead of setterm to set colors, seems to work with more
terminals.
Signed-off-by: Daniel Serpell <daniel.serpell@gmail.com>
gitlog.sh: 6d24d857fb6c2f7e810954adaca1990599906f07
--- a/gitlog.sh
+++ b/gitlog.sh
@@ -11,11 +11,11 @@
if [ "$1" = "-c" ]; then
shift
- colheader=$(setterm -foreground green)
- colauthor=$(setterm -foreground cyan)
- colcommitter=$(setterm -foreground magenta)
- colsignoff=$(setterm -foreground yellow)
- coldefault=$(setterm -foreground default)
+ colheader="$(tput setaf 2)" # Green, see terminfo(5), "Color Handling"
+ colauthor="$(tput setaf 6)" # Cyan
+ colcommitter="$(tput setaf 5)" # Magenta
+ colsignoff="$(tput setaf 3)" # Yellow
+ coldefault="$(tput op)" # Restore default
else
colheader=
colauthor=
^ permalink raw reply
* Re: [PATCH] Colorized git log
From: Petr Baudis @ 2005-04-22 0:54 UTC (permalink / raw)
To: Daniel Serpell; +Cc: GIT Mailing Lists
In-Reply-To: <f0796bb7050421174647943f0c@mail.gmail.com>
Dear diary, on Fri, Apr 22, 2005 at 02:46:19AM CEST, I got a letter
where Daniel Serpell <daniel.serpell@gmail.com> told me that...
> Hi!
Hi,
> On 4/21/05, Petr Baudis <pasky@ucw.cz> wrote:
> >
> > I made git log colorized if you pass it -c in current git-pasky.
> >
>
> This has two problems, solved in two patches:
could you please sign them off?
> * A space is added in front of header lines when you use color.
Oh, good catch, thanks.
> * It does not work in my (Debian) xterm. This is because here
> "setterm" only works with TERM=linux.
Duh. And they say "Where possible terminfo is consulted to find the
string to use." in their manual page. :/
> gitlog.sh: 6d24d857fb6c2f7e810954adaca1990599906f07
> --- a/gitlog.sh
> +++ b/gitlog.sh
> @@ -11,11 +11,11 @@
>
> if [ "$1" = "-c" ]; then
> shift
> - colheader=$(setterm -foreground green)
> - colauthor=$(setterm -foreground cyan)
> - colcommitter=$(setterm -foreground magenta)
> - colsignoff=$(setterm -foreground yellow)
> - coldefault=$(setterm -foreground default)
> + colheader="$(tput setaf 2)"
> + colauthor="$(tput setaf 6)"
> + colcommitter="$(tput setaf 5)"
> + colsignoff="$(tput setaf 3)"
> + coldefault="$(tput op)"
> else
> colheader=
> colauthor=
Please at least stick the colors in comments after the assignment.
Not everyone knows ANSI color codes off-hand (the last thing I've
memorized were BIOS color codes in the distant DOS days).
--
Petr "Pasky" Baudis
Stuff: http://pasky.or.cz/
C++: an octopus made by nailing extra legs onto a dog. -- Steve Taylor
^ permalink raw reply
* [PATCH] Colorized git log
From: Daniel Serpell @ 2005-04-22 0:46 UTC (permalink / raw)
To: GIT Mailing Lists; +Cc: Petr Baudis
In-Reply-To: <20050421224229.GR7443@pasky.ji.cz>
Hi!
On 4/21/05, Petr Baudis <pasky@ucw.cz> wrote:
>
> I made git log colorized if you pass it -c in current git-pasky.
>
This has two problems, solved in two patches:
* A space is added in front of header lines when you use color.
* It does not work in my (Debian) xterm. This is because here
"setterm" only works with TERM=linux.
-------------------------
Strip space in front of colorized header lines.
gitlog.sh: 6d24d857fb6c2f7e810954adaca1990599906f07
--- a/gitlog.sh
+++ b/gitlog.sh
@@ -27,7 +27,7 @@ fi
base=$(gitXnormid.sh -c $1) || exit 1
rev-tree $base | sort -rn | while read time commit parents; do
- echo $colheader commit ${commit%:*} $coldefault;
+ echo $colheader""commit ${commit%:*} $coldefault;
cat-file commit $commit | \
while read key rest; do
case "$key" in
@@ -43,10 +43,10 @@ rev-tree $base | sort -rn | while read t
dtz=${tz/+/+ }; dtz=${dtz/-/- }
pdate="$(date -Rud "1970-01-01 UTC + $sec sec $dtz" 2>/dev/null)"
if [ "$pdate" ]; then
- echo -n $color $key $rest | sed "s/>.*/> ${pdate/+0000/$tz}/"
+ echo -n $color$key $rest | sed "s/>.*/> ${pdate/+0000/$tz}/"
echo $coldefault
else
- echo $color $key $rest $coldefault
+ echo $color$key $rest $coldefault
fi
;;
"")
@@ -56,7 +56,7 @@ rev-tree $base | sort -rn | while read t
'
;;
*)
- echo $colheader $key $rest $coldefault
+ echo $colheader$key $rest $coldefault
;;
esac
-------------------------
Uses tput instead of setterm to set colors, seems to work with more
terminals.
gitlog.sh: 6d24d857fb6c2f7e810954adaca1990599906f07
--- a/gitlog.sh
+++ b/gitlog.sh
@@ -11,11 +11,11 @@
if [ "$1" = "-c" ]; then
shift
- colheader=$(setterm -foreground green)
- colauthor=$(setterm -foreground cyan)
- colcommitter=$(setterm -foreground magenta)
- colsignoff=$(setterm -foreground yellow)
- coldefault=$(setterm -foreground default)
+ colheader="$(tput setaf 2)"
+ colauthor="$(tput setaf 6)"
+ colcommitter="$(tput setaf 5)"
+ colsignoff="$(tput setaf 3)"
+ coldefault="$(tput op)"
else
colheader=
colauthor=
^ permalink raw reply
* Re: "GIT_INDEX_FILE" environment variable
From: Junio C Hamano @ 2005-04-22 0:21 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Git Mailing List
In-Reply-To: <Pine.LNX.4.58.0504211100330.2344@ppc970.osdl.org>
>>>>> "LT" == Linus Torvalds <torvalds@osdl.org> writes:
LT> Add support for a "GIT_INDEX_FILE" environment variable.
LT> We use that to specify alternative index files, which can be useful
LT> if you want to (for example) generate a temporary index file to do
LT> some specific operation that you don't want to mess with your main
LT> one with.
LT> It defaults to the regular ".git/index" if it hasn't been specified.
This is all good. I have a related issue I'd like to hear your
opinion about.
When I am not in the top-level directory, relative to the tree
structure $GIT_INDEX_FILE describes, obviously I cannot just say
"show-diff path-pattern" (or even just "show-diff") without
first chdir'ing to the top. My current workaround I use in the
jit-show-diff wrapper script is quite ugly:
- Starting from dir="${PWD-"$(pwd)"}", repeatedly do
dir=$(dirname dir) until I find a $dir/.git directory. Call
the first directory I find that has .git subdirectory
$GIT_PROJECT_TOP.
- At the same time, inspect GIT_INDEX_FILE and
SHA1_FILE_DIRECTORY environment variables. If they are not
set, set them to $GIT_PROJECT_TOP/.git/index and
$GIT_PROJECT_TOP/.git/objects, respectively and export them.
- Figure out the name of the current working directory relative
to $GIT_PROJECT_TOP. I'll call this value $R for brevity in
the following description.
- chdir to $GIT_PROJECT_TOP and run "show-diff" with the
original flags and _all_ the user supplied paths prefixed
with $R.
To illustrate what I just said:
$ /bin/ls -aF
./ ../ .git/ a/
$ /bin/ls -aF .git
. ../ HEAD index objects/
$ cd a
$ /bin/ls -aF
. ../ bar foo/
$ show-diff -r foo ; # of course this does not work.
$ jit-show-diff -r foo
The wrapper figures out that .. is the project top to chdir
to, and $R is "a/". Using these values, it eventually calls:
cd .. ; show-diff -r "a/foo"
This is not so hard to arrange in the wrapper, but this is quite
brittle. The show-diff command happens to take only -r, -z, and
-q flag parameters so the wrapper can prefix $R to all the other
paramters, but for other git core commands when to prefix $R and
when not to soon becomes a maintenance nightmare.
I am thinking about an alternative way of doing the above by
some modifications to the git core. I think the root of this
problem is that there is no equivalent to GIT_INDEX_FILE and
SHA1_FILE_DIRECTORY that tells the core git where the project
top directory (i.e. the root of the working tree that
corresponds to what $GIT_INDEX_FILE describes) is.
I am wondering if this alternative is acceptable by you before I
spend too much time on it.
- A new environment variable GIT_WORKING_TREE points at the
root of the working tree.
- Each git core command [*1*] that looks at the working tree is
modified to take the user supplied pathname as a path
relative to the current working directory, and use
GIT_WORKING_TREE value to figure out which path the user is
talking about, relative to the tree structure GIT_INDEX_FILE
describes.
There is no need for jit-show-diff-wrapper when the above change
happens. The user (or Cogito) has to set and export
GIT_WORKING_TREE once, and whereever the user happens to be the
core git command would just work as expected.
What do you think?
[Footnotes]
*1* Yes I am aware that there are tons of them that need this
surgery if we wanted to take this approach.
^ permalink raw reply
* Re: [PATCH] multi item packed files
From: Chris Mason @ 2005-04-22 0:16 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Krzysztof Halasa, git
In-Reply-To: <Pine.LNX.4.58.0504211530370.2344@ppc970.osdl.org>
On Thursday 21 April 2005 18:47, Linus Torvalds wrote:
> On Thu, 21 Apr 2005, Chris Mason wrote:
> > Shrug, we shouldn't need help from the kernel for something like this.
> > git as a database hits worst case scenarios for almost every FS.
[ ... ]
We somewhat agree on most of this, I snipped out the parts that aren't worth
nitpicking over. git is really fast right now, and I'm all for throwing
drive space at things to solve problems. I just don't think we have to throw
as much space at it as we are.
> The _seek_ issue is real, but git actually has a very nice architecture
> even there: not only dos it cache really really well (and you can do a
> simple "ls-tree $(cat .git/HEAD)" and populate the case from the results),
> but the low level of indirection in a git archive means that it's almost
> totally prefetchable with near-perfect access patterns.
We can sort by the files before reading them in, but even if we order things
perfectly, we're spreading the io out too much across the drive. It works
right now because the git archive is relatively dense. At a few hundred MB
when we order things properly the drive head isn't moving that much.
At 3-6 GB this hurts more. The data gets farther apart as things age, and
drive performance rots away. I'll never convince you without numbers, which
means I'll have to wait for the full load of old history and try it out ;)
-chris
^ permalink raw reply
* Re: [PATCH] Add DEST Makefile variable
From: Pavel Roskin @ 2005-04-21 23:37 UTC (permalink / raw)
To: Matthias Urlichs; +Cc: Junio C Hamano, git
In-Reply-To: <20050421230732.GA13311@kiste.smurf.noris.de>
Hello!
On Fri, 2005-04-22 at 01:07 +0200, Matthias Urlichs wrote:
> Hi,
>
> Junio C Hamano:
> > I sent essentially the same some time ago and got a comment to
> > follow established naming convention.
> >
> Well, for a Makefile which installs in basically one directory, that
> seems to be overkill.
>
> > # DESTDIR=
> > BINDIR=$(HOME)/bin
> > install foobar $(DESTDIR)$(BINDIR)/
> >
> That doesn't make sense; if you set DESTDIR, you are not going to
> install in $HOME.
It makes sense to stick with conventions. DESTDIR is almost always set
by a script for making a package, and that script will likely set prefix
to /usr.
prefix is set to $HOME temporarily. It should be changed to /usr/local
some day. It's not uncommon for $HOME to be shared between systems with
different architectures, so ideally no binaries should be installed
there. I guess $HOME is used to save typing "su" or redefining prefix
in a project that changes every 10 minutes or so. But once git
stabilizes, there will be no excuse.
By the way, we need to change prefix and bindir to be lowercase for
compatibility with GNU standards. Also, ifdef is not needed - command
line trumps even unconditional variable assignments. Another thing to
fix - DESTDIR is not used when bindir is created.
Signed-off-by: Pavel Roskin <proski@gnu.org>
--- a/Makefile
+++ b/Makefile
@@ -14,12 +14,10 @@
# (my ext3 doesn't).
CFLAGS=-g -O2 -Wall
-ifndef PREFIX
-PREFIX=$(HOME)
-endif
-ifndef BINDIR
-BINDIR=$(PREFIX)/bin
-endif
+# Should be changed to /usr/local
+prefix=$(HOME)
+
+bindir=$(prefix)/bin
CC=gcc
AR=ar
@@ -81,8 +79,8 @@ gitversion.sh: $(VERSION)
install: $(PROG) $(GEN_SCRIPT)
- install -m755 -d $(BINDIR)
- install $(PROG) $(SCRIPT) $(GEN_SCRIPT) $(DESTDIR)$(BINDIR)
+ install -m755 -d $(DESTDIR)$(bindir)
+ install $(PROG) $(SCRIPT) $(GEN_SCRIPT) $(DESTDIR)$(bindir)
clean:
rm -f *.o mozilla-sha1/*.o $(PROG) $(GEN_SCRIPT) $(LIB_FILE)
--
Regards,
Pavel Roskin
^ permalink raw reply
* Porting to old zlib (deflateBound) & old mktemp (e.g., Red Hat Linux 9)
From: David A. Wheeler @ 2005-04-21 23:27 UTC (permalink / raw)
To: Randy.Dunlap; +Cc: jschopp, git
In-Reply-To: <20050421102552.544c70fd.rddunlap@osdl.org>
On Thu, 21 Apr 2005 12:19:32 -0500 Joel Schopp wrote:
>| I downloaded git-pasky 0.6.2. I cannot compile it because my zlib
>| version is 1.1.4 and git-pasky relies on function deflateBound() which
>| wasn't introduced until zlib version 1.2.x Is there a patch out there
>| to work around this and maybe conditionally compile based on the zlib
>| version?
>
>
Here's a quick (read: nasty, dreadful) hack to port git
to older systems like Red Hat Linux 9 which have old versions
of zlib & mktemp. Someone who actually spent two seconds
on this can no doubt give you a better solution, but it "worked for me".
Edit sha1_file.c, and change the line:
size = deflateBound(&stream, len);
to
size = len + 1024; /* 1024=emergency extra space */
The "deflateBound" call just finds out the maximum amount of allocation
space.
The documentation says that "deflateBound() may return a
conservative value that may be larger than /sourceLen/" in certain cases,
which worried me. So to be safe I just added a big pile of excess space
to "len";
I suspect that "size = len" is sufficient but I didn't investigate it.
If you're trying to get this to work on Red Hat Linux 9, you'll
have another problem too: old versions of "mktemp"
don't support the "-t" option. Other old distributions will
have the same problem. To find these cases, do:
grep "mktemp.*-t" *
and edit all the files to remove the "-t" option from mktemp.
That's the bare minimum to make it work; a much
cleaner solution would to specify the tempdir, e.g.,:
mktemp ${TMPDIR:-/tmp/}gitci.XXXXX
or even more portably, write the shell code to set TMPDIR to "/tmp"
locally if it's not set, then use $TMPDIR everywhere.
Not a good final solution, but enough to get started in the interim.
In long term, this should be made more portable, but it's
only ~2 weeks old after all. Some people are trying to fly this plane
to transport a buffalo herd, while others are working to attach the
wings :-).
--- David A. Wheeler
^ permalink raw reply
* [PATCH] README spellcheck again
From: Pavel Roskin @ 2005-04-21 23:20 UTC (permalink / raw)
To: git
Hello!
Patch against current git, applies cleanly to both linus and pasky
branches.
Signed-off-by: Pavel Roskin <proski@gnu.org>
--- a/README
+++ b/README
@@ -95,7 +95,7 @@ The object types in some more detail:
In particular, since the blob is entirely defined by its data,
if two files in a directory tree (or in multiple different
versions of the repository) have the same contents, they will
- share the same blob object. The object is toally independent
+ share the same blob object. The object is totally independent
of it's location in the directory tree, and renaming a file does
not change the object that file is associated with in any way.
@@ -150,7 +150,7 @@ CHANGESET: The "changeset" object is an
actually have any relationship with the result, for example.
Note on changesets: unlike real SCM's, changesets do not contain
- rename information or file mode chane information. All of that
+ rename information or file mode change information. All of that
is implicit in the trees involved (the result tree, and the
result trees of the parents), and describing that makes no sense
in this idiotic file manager.
@@ -322,7 +322,7 @@ main combinations:
changes in your working directory (ie "update-cache").
However, if you decide to jump to a new version, or check out
- somebody elses version, or just restore a previous tree, you'd
+ somebody else's version, or just restore a previous tree, you'd
populate your index file with read-tree, and then you need to
check out the result with
--
Regards,
Pavel Roskin
^ permalink raw reply
* Re: [PATCH] Docs update
From: David Greaves @ 2005-04-21 23:10 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Petr Baudis, GIT Mailing Lists
In-Reply-To: <7vy8bbd9n4.fsf@assigned-by-dhcp.cox.net>
Junio C Hamano wrote:
>>>>>>"DG" == David Greaves <david@dgreaves.com> writes:
> Looks nice. I agree with Petr's comment that separating core part
> and Cogito part would be good
OK
> And the option to use working tree is not having the --cached
> flag you describe later. Please also update the usage at the
> top as well:
<snip>
> This command can take commit ID in place of tree ID.
Yep, the intention is to do all the core docs, get consistent use of
<sha1> or <tree> or <id> etc etc and then patch all the usage()s at once.
Thanks for the comments - will edit in the am.
David
^ permalink raw reply
* Re: [PATCH] Add DEST Makefile variable
From: Matthias Urlichs @ 2005-04-21 23:07 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vr7h3d9cu.fsf@assigned-by-dhcp.cox.net>
Hi,
Junio C Hamano:
> I sent essentially the same some time ago and got a comment to
> follow established naming convention.
>
Well, for a Makefile which installs in basically one directory, that
seems to be overkill.
> # DESTDIR=
> BINDIR=$(HOME)/bin
> install foobar $(DESTDIR)$(BINDIR)/
>
That doesn't make sense; if you set DESTDIR, you are not going to
install in $HOME.
--
Matthias Urlichs | {M:U} IT Design @ m-u-it.de | smurf@smurf.noris.de
^ permalink raw reply
* Re: [PATCH] Missing linefeeds
From: Matthias Urlichs @ 2005-04-21 23:08 UTC (permalink / raw)
To: Petr Baudis; +Cc: git
In-Reply-To: <20050421162614.GF30991@pasky.ji.cz>
Hi,
Petr Baudis:
> Why? report() already prints linefeed.
>
Ah, it didn't when I wrote this.
--
Matthias Urlichs | {M:U} IT Design @ m-u-it.de | smurf@smurf.noris.de
^ permalink raw reply
* Re: [PATCH] Improve usage messages
From: Junio C Hamano @ 2005-04-21 23:02 UTC (permalink / raw)
To: Matthias Urlichs; +Cc: git
In-Reply-To: <20050421124152.A28137F87D@smurf.noris.de>
>>>>> "MU" == Matthias Urlichs <smurf@smurf.noris.de> writes:
MU> Index: diff-tree.c
MU> +static const char diff_tree_usage[] =
MU> + "diff-tree [ -r (recurse) | -z (\\0-terminate) ]"
MU> + "\n\t<tree sha1> <tree sha1>";
I think we already have this, and Pasky's right to say the
(recurse) and (\0-terminate) should not be there.
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox