Re: [ANNOUNCE] git-pasky-0.6.3 && request for testing
On Fri, Apr 22, 2005 at 05:09:31AM +0200, Petr Baudis wrote: > Hello, > > FYI, I've released git-pasky-0.6.3 earlier in the night. Hm, fun thing to try: go into a kernel git tree. rm Makefile git diff Watch it as it thinks that every Makefile in the kernel tree is now gone... thanks, greg k-h - To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Mozilla SHA1 implementation
Linus Torvalds writes:
> I've just integrated the Mozilla SHA1 library implementation that Adgar
> Toernig sent me into the standard git archive (but I did the integration
> differently).
Here is a new PPC SHA1 patch that integrates better with this...
> Interestingly, the Mozilla SHA1 code is about twice as fast as the openssl
> code on my G5, and judging by the disassembly, it's because it's much
> simpler. I think the openssl people have unrolled all the loops totally,
> which tends to be a disaster on any half-way modern CPU. But hey, it could
> be something as simple as optimization flags too.
Very interesting. On my G4 powerbook (since I am at LCA), for a
fsck-cache on a linux-2.6 tree, it takes 6.6 seconds with the openssl
SHA1, 10.7 seconds with the Mozilla SHA1, and ~5.8 seconds with my
SHA1. I'll test it on a G5 tonight, hopefully.
Paul.
diff -urN git.orig/Makefile git/Makefile
--- git.orig/Makefile 2005-04-22 16:23:44.0 +1000
+++ git/Makefile2005-04-22 16:43:31.0 +1000
@@ -34,9 +34,14 @@
SHA1_HEADER="mozilla-sha1/sha1.h"
LIB_OBJS += mozilla-sha1/sha1.o
else
+ifdef PPC_SHA1
+ SHA1_HEADER="ppc/sha1.h"
+ LIB_OBJS += ppc/sha1.o ppc/sha1ppc.o
+else
SHA1_HEADER=
LIBS += -lssl
endif
+endif
CFLAGS += '-DSHA1_HEADER=$(SHA1_HEADER)'
@@ -77,7 +82,7 @@
write-tree.o: $(LIB_H)
clean:
- rm -f *.o mozilla-sha1/*.o $(PROG) $(LIB_FILE)
+ rm -f *.o mozilla-sha1/*.o ppc/*.o $(PROG) $(LIB_FILE)
backup: clean
cd .. ; tar czvf dircache.tar.gz dir-cache
diff -urN git.orig/ppc/sha1.c git/ppc/sha1.c
--- /dev/null 2005-04-04 12:56:19.0 +1000
+++ git/ppc/sha1.c 2005-04-22 16:29:19.0 +1000
@@ -0,0 +1,72 @@
+/*
+ * SHA-1 implementation.
+ *
+ * Copyright (C) 2005 Paul Mackerras <[EMAIL PROTECTED]>
+ *
+ * This version assumes we are running on a big-endian machine.
+ * It calls an external sha1_core() to process blocks of 64 bytes.
+ */
+#include
+#include
+#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/ppc/sha1.h git/ppc/sha1.h
--- /dev/null 2005-04-04 12:56:19.0 +1000
+++ git/ppc/sha1.h 2005-04-22 16:45:28.0 +1000
@@ -0,0 +1,20 @@
+/*
+ * SHA-1 implementation.
+ *
+ * Copyright (C) 2005 Paul Mackerras <[EMAIL PROTECTED]>
+ */
+#include
+
+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);
diff -urN git.orig/ppc/sha1ppc.S git/ppc/sha1ppc.S
--- /dev/null 2005-04-04 12:56:19.0 +1000
+++ git/ppc/sha1ppc.S 2005-04-22 16:29:19.0 +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)
+#defin
Re: "GIT_INDEX_FILE" environment variable
> "LT" == Linus Torvalds <[EMAIL PROTECTED]> writes:
LT> I'd _really_ prefer to just try to teach people to work from
LT> the "top" directory instead.
I share the sentiment, but I do not think that is an option.
There are three possibilities:
- Train people to always work from the top and never support
working in subdirectory at any layer.
- Admit that people cannot be trained, and support it at Cogito
layer.
- Further admit that to support it without core layer help,
what Cogito layer needs to do involves quite a lot of "yuck"
factor.
For somebody whose primary concern is to pull the whole tree
from outside and watch out for merge conflicts, always working
from the top may be a practical option. But you also have to
consider that the people who actually feed those whole trees to
you probably do most of their work in their subdirectories. You
would want to make life easier for them in order for you to get
high-quality results from them.
I initially thought that the third one in the above list was the
case, and that's why I asked. After reviewing the core layer to
see the extent of the damage the proposed change would cause, to
my surprise, it turns out that it is not all that bad. It
probably is not surprising to you because of the way you
designed things --- doing as much as possible in the dircache,
and avoiding looking at the working tree.
The commands I would want to take paths relative to the user cwd
are quite limited; note that I just want these available to the
user and I do not care which one, the core or Cogito, groks the
cwd relative paths:
check-files paths...
show-diff [-R] [-q] [-s] [-z] [paths...]
update-cache [--add] [--remove] [--refresh]
[--cacheinfo mode blob-id] paths...
The only parameters that needs $R prefixing are the "paths..."
above. I think the wrapper layer can manage without the help
from the core layer for these small number of commands using the
workaround I outlined in my previous message.
In addition, there is another one that looks at the working
tree:
diff-cache [-z] [-r] [--cached] tree-id
But this one is even easier. The wrapper layer needs to figure
out the project top, chdir to it and run the underlying
diff-cache there.
LT> I really don't like it that much, but to some degree it
LT> obviously is exactly what "--prefix=" does to
LT> checkout-cache. It's basically saying that all normal file
LT> operations have to be prefixed with a magic string.
More or less so. I actually was thinking about going a bit more
than just prefix, and normalizing paths in the core layer, in
order to get something like the following operate sensibly:
$ find . -type f | xargs update-cache
$ cd mozilla-sha1 && show-diff ../*.h
But this may be going a bit overboard.
LT> And git really doesn't do too many of those, so maybe it's
LT> ok. What would the patch look like? I don't really love the
LT> idea, but if the patch is clean enough...
Please forget this one for a bit. I'm attacking this from both
fronts.
Core changes supporting the "project root" notion is what we are
discussing here. As I said, I do not think it would be a huge
change as I feared initially, but after the initial "let's get
the list of commands and analyze how they use the paths" phase,
I have backburnered this approach, at least for now. Working
around in the wrapper layer without core support seems to be a
viable option, especially now I know that what needs to be
wrapped are not that many, and that is what I've been looking
at this evening.
For your amusement, eh, rather, to test your "yuck" tolerance
;-), I've attached two scripts. jit-find-index is a helper
script for wrappers. It finds the project root and computes $R
prefix; the wrappers call it and eval its result.
jit-update-cache is a wrapper to run update-cache inside of
subdirectory. This is the worst example among the four wrappers.
Not-Signed-off-yet-by: Junio C Hamano <[EMAIL PROTECTED]>
---
jit-find-index | 60 ++
jit-update-cache | 23 +
2 files changed, 83 insertions(+)
--- /dev/null 2005-03-19 15:28:25.0 -0800
+++ jit-find-index 2005-04-21 22:59:55.0 -0700
@@ -0,0 +1,60 @@
+#!/bin/sh
+
+sq=s/\'/\''\\'\'\'/g ;# see sq-expand in show-diff.c
+
+lookfor_index=${GIT_INDEX_FILE-.git/index}
+lookfor_object=${SHA1_FILE_DIRECTORY-.git/objects}
+
+index= object= project_top=
+
+# No point in looking for something specified with an absolute path.
+case "$lookfor_index" in
+/*) index="$lookfor_index" ;;
+esac
+case "$lookfor_object" in
+/*) object="$lookfor_object" ;;
+esac
+
+# Beware of symlinks. We need to find out what the current directory
+# is called relative to the path recorded in the dircache.
+dir=${PWD-$(pwd)} cwd="$dir" down=
+
+while
+case "$dir" in /) break ;; esac && # we searched all.
+case ",$index,$object,$project_top," in
+*,,*) ;;
+*)break ;; # we now ha
[PATCH] optimized SHA1 for powerpc
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.0 +1000
+++ git/Makefile2005-04-22 15:11:28.0 +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.h2005-04-22 15:21:10.0 +1000
+++ git/cache.h 2005-04-22 13:57:36.0 +1000
@@ -12,7 +12,7 @@
#include
#include
-#include
+#include "sha1.h"
#include
/*
diff -urN git.orig/sha1.c git/sha1.c
--- /dev/null 2005-04-04 12:56:19.0 +1000
+++ git/sha1.c 2005-04-22 15:17:27.0 +1000
@@ -0,0 +1,72 @@
+/*
+ * SHA-1 implementation.
+ *
+ * Copyright (C) 2005 Paul Mackerras <[EMAIL PROTECTED]>
+ *
+ * This version assumes we are running on a big-endian machine.
+ * It calls an external sha1_core() to process blocks of 64 bytes.
+ */
+#include
+#include
+#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.0 +1000
+++ git/sha1.h 2005-04-22 15:06:53.0 +1000
@@ -0,0 +1,19 @@
+#ifndef __powerpc__
+#include
+#else
+#include
+
+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.0 +1000
+++ git/sha1ppc.S 2005-04-22 15:18:19.0 +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
Re: "GIT_INDEX_FILE" environment variable
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 - To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [ANNOUNCE] git-pasky-0.6.3 && request for testing
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 <[EMAIL PROTECTED]> Index: git === --- 0a9ee5a4d947b998a7ce489242800b39f985/git (mode:100755 sha1:39969debd59ed51c57973c819cdcc3ca8a7da819) +++ uncommitted/git (mode:100755) @@ -35,7 +35,7 @@ forkBNAME BRANCH_DIR [COMMIT_ID] help initRSYNC_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 === --- 0a9ee5a4d947b998a7ce489242800b39f985/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. - To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: ia64 git pull
Petr Baudis <[EMAIL PROTECTED]> 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 - To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] Eliminate use of mktemp's "-t" option
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 commit 5f926b684025b83e34386bf8e4ef30a97e2ae5ec tree 61059575269ed1027cfb66543251e182f87d1064 parent dd69ca5f806c8b10bb29ecb8d77c88be007c981c author David A. Wheeler <[EMAIL PROTECTED]> 1114138972 -0400 committer David A. Wheeler <[EMAIL PROTECTED]> 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.XX) -todo=$(mktemp -t gitapply.XX) -patchfifo=$(mktemp -t gitapply.XX) +if [ -z "$TMPDIR"]; then + TMPDIR=/tmp +fi + +gonefile=$(mktemp "$TMPDIR/gitapply.XX") +todo=$(mktemp "$TMPDIR/gitapply.XX") +patchfifo=$(mktemp "$TMPDIR/gitapply.XX") 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.XX) +LOGMSG=$(mktemp "$TMPDIR/gitci.XX") 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.XX) + greptmp=$(mktemp "$TMPDIR/gitci.XX") 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.XX) +if [ -z "$TMPDIR"]; then + TMPDIR=/tmp +fi + +diffdir=$(mktemp -d "$TMPDIR/gitdiff.XX") 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.XX) + export GIT_INDEX_FILE=$(mktemp "$TMPDIR/gitdiff.XX") read-tree $(gitXnormid.sh "$id1") update-cache --refresh fi Index: gitmerge.sh === --- 6a612d42afdba20fd2150e319a689ed451b010e4/gitmerge.sh (mode:100755 sha1:683755729b6f689ea43c692712fad6e51eeac354) +++ 61059575269ed1027cfb66543251e182f87d1064/gitmerge.sh (mode:100755 sha
[ANNOUNCE] git-pasky-0.6.3 && request for testing
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 - To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] git-pasky spec file
* Petr Baudis ([EMAIL PROTECTED]) wrote: > Dear diary, on Fri, Apr 22, 2005 at 03:55:21AM CEST, I got a letter > where Chris Wright <[EMAIL PROTECTED]> 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.0 -0800 > > +++ git-pasky-0.6.3/git.spec2005-04-21 18:42:18.0 -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 - To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] git-pasky spec file
Dear diary, on Fri, Apr 22, 2005 at 03:55:21AM CEST, I got a letter where Chris Wright <[EMAIL PROTECTED]> 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.0 -0800 > +++ git-pasky-0.6.3/git.spec 2005-04-21 18:42:18.0 -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 - To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: ia64 git pull
> Petr Baudis <[EMAIL PROTECTED]> 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 - To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] git-pasky spec file
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 <[EMAIL PROTECTED]>
--- /dev/null 1969-12-31 16:00:00.0 -0800
+++ git-pasky-0.6.3/git.spec2005-04-21 18:42:18.0 -0700
@@ -0,0 +1,43 @@
+Name: git
+Version: 0.6.3
+Release: 1
+Vendor:Petr Baudis <[EMAIL PROTECTED]>
+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 <[EMAIL PROTECTED]> 0.6.3-1
+- Initial rpm build
-
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: ia64 git pull
Dear diary, on Fri, Apr 22, 2005 at 03:48:35AM CEST, I got a letter where Inaky Perez-Gonzalez <[EMAIL PROTECTED]> told me that... > > Petr Baudis <[EMAIL PROTECTED]> 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 - To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] Colored log on any ANSI capable terminal
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 <[EMAIL PROTECTED]> --- 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 - To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] Colorized git log
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 - To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] Colorized git log
Hi!
On 4/21/05, Petr Baudis <[EMAIL PROTECTED]> wrote:
> Dear diary, on Fri, Apr 22, 2005 at 02:46:19AM CEST, I got a letter
> where Daniel Serpell <[EMAIL PROTECTED]> 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 <[EMAIL PROTECTED]>
+++ 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/+/$tz}/"
+ echo -n $color$key $rest | sed "s/>.*/>
${pdate/+/$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 <[EMAIL PROTECTED]>
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=
-
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] Colorized git log
Dear diary, on Fri, Apr 22, 2005 at 02:46:19AM CEST, I got a letter where Daniel Serpell <[EMAIL PROTECTED]> told me that... > Hi! Hi, > On 4/21/05, Petr Baudis <[EMAIL PROTECTED]> 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 - To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] Colorized git log
Hi!
On 4/21/05, Petr Baudis <[EMAIL PROTECTED]> 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/+/$tz}/"
+ echo -n $color$key $rest | sed "s/>.*/>
${pdate/+/$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=
-
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: "GIT_INDEX_FILE" environment variable
> "LT" == Linus Torvalds <[EMAIL PROTECTED]> 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.
-
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] multi item packed files
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 - To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] Add DEST Makefile variable
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 <[EMAIL PROTECTED]> --- 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 - To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Porting to old zlib (deflateBound) & old mktemp (e.g., Red Hat Linux 9)
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.X
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
-
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] README spellcheck again
Hello! Patch against current git, applies cleanly to both linus and pasky branches. Signed-off-by: Pavel Roskin <[EMAIL PROTECTED]> --- 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 - To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] Add DEST Makefile variable
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 | [EMAIL PROTECTED]
-
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] Docs update
Junio C Hamano wrote: "DG" == David Greaves <[EMAIL PROTECTED]> 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: 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 or or etc etc and then patch all the usage()s at once. Thanks for the comments - will edit in the am. David - To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] Missing linefeeds
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 | [EMAIL PROTECTED]
-
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] Improve usage messages
> "MU" == Matthias Urlichs <[EMAIL PROTECTED]> writes: MU> Index: diff-tree.c MU> +static const char diff_tree_usage[] = MU> + "diff-tree [ -r (recurse) | -z (\\0-terminate) ]" MU> + "\n\t "; I think we already have this, and Pasky's right to say the (recurse) and (\0-terminate) should not be there. - To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] Add DEST Makefile variable
> "MU" == Matthias Urlichs <[EMAIL PROTECTED]> writes: MU> # (my ext3 doesn't). MU> CFLAGS=-g -O3 -Wall MU> +DEST=$(HOME)/bin MU> install: $(PROG) $(GEN_SCRIPT) MU> - install $(PROG) $(SCRIPT) $(GEN_SCRIPT) $(HOME)/bin/ MU> + install $(PROG) $(SCRIPT) $(GEN_SCRIPT) $(DEST)/ I sent essentially the same some time ago and got a comment to follow established naming convention. Many people seem to call What you are calling DEST above BINDIR and DEST or DESTDIR usually means something completely different. It goes like this: # DESTDIR= BINDIR=$(HOME)/bin install: install foobar $(DESTDIR)$(BINDIR)/ $ su ;# personal machine install by local root # make BINDIR=/usr/local/bin install # binary package creation $ make BINDIR=/usr/bin DESTDIR=/var/tmp/tmp-inst install $ tar Ccf /var/tmp/tmp-inst tarball.tar.gz . - To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Mozilla SHA1 implementation
Linus Torvalds wrote: > > I've just integrated the Mozilla SHA1 library implementation into the > standard git archive Thanks. In the mood for another compatibility hack? My zlib doesn't have deflateBound and browsing through the git-ml archive it seems I'm not the only one. How about putting this snippet into some header file? #if ZLIB_VERNUM < 0x1200 #define deflateBound(c,s) ((s) + (((s) + 7) >> 3) + (((s) + 63) >> 6) + 11) #endif The formula is the conservative upper bound from zlib-1.2.2. Ciao, ET. - To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: ia64 git pull
Dear diary, on Fri, Apr 22, 2005 at 12:29:07AM CEST, I got a letter where Linus Torvalds <[EMAIL PROTECTED]> told me that... > On Thu, 21 Apr 2005 [EMAIL PROTECTED] wrote: > > > > I can't quite see how to manage multiple "heads" in git. I notice that in > > your tree on kernel.org that .git/HEAD is a symlink to heads/master ... > > perhaps that is a clue. > > It's mainly a clue to bad practice, in my opinion. I personally like the > "one repository, one head" approach, and if you want multiple heads you > just do multiple repositories (and you can then mix just the object > database - set your SHA1_FILE_DIRECTORY environment variable to point to > the shared object database, and you're good to go). There are two points regarding this: (i) You need to track heads of remote branches anyway. (ii) I want an easy way for user to refer to head of another working tree on the same repository (so that you can do just git merge testing). This is why the multiple heads are there, and it's actually everything they _do_. There's nothing more behind it. -- Petr "Pasky" Baudis Stuff: http://pasky.or.cz/ C++: an octopus made by nailing extra legs onto a dog. -- Steve Taylor - To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] Docs update
> "DG" == David Greaves <[EMAIL PROTECTED]> writes: Looks nice. I agree with Petr's comment that separating core part and Cogito part would be good, and I would appreciate if you pushed the core part documentation to Linus as well. Some nitpicks and notes on your core part description. DG> commit-tree DG> - commit-tree [-p ]* < changelog DG> + commit-tree [-p ...] < changelog The above does not describe what commit-tree expects. It wants commit-tree [-p ]* +A commit object usually has 1 parent (a commit after a change) or 2 DG> +parents (a merge) although there is no reason it cannot have more than DG> +2 parents. I'd rewrite the "or 2 parents..." part to "up to 16 parents. More than one parent represents merge of branches that led to them." DG> +If not provided, commit-tree uses your name, hostname and domain to DG> +provide author and committer info. This can be overridden using the DG> +following environment variables. DG> + ... DG> +(nb <,> and CRs are stripped) CRs are kept. It removes '\n' (which is not necessarily LF). DG> +diff-cache DG> + diff-cache [-r] [-z] DG> + DG> +Compares the content and mode of the blobs found via a tree object DG> +with the content of the current cache and, optionally, the stat state DG> +of the file on disk. 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: diff-cache [-r] [-z] [--cached] DG> +In the special case of the file being changed on disk and out of sync with the cache, the sha1 DG> + DG> +Operating Modes Is the description truncated after "the sha1"??? DG> DG> diff-tree DG> - diff-tree [-r] [-z] DG> + diff-tree [-r] [-z] This command can take commit ID in place of tree ID. - To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] multi item packed files
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. I really disagree. > We've got: > > 1) subdirectories with lots of files > 2) wasted space for tiny files > 3) files that are likely to be accessed together spread across the whole disk On the other hand, git does a lot of things that are just _lovely_ for a filesystem: - it never rewrites a file. Rewriting a file is unquestionably _the_ single worst access pattern for any filesystem. In contrast, never writing to a file again means that filesystems can optimize their layout and that things like defragmentation actually works. - it caches beautifully, and efficiently. Part of it comes from never modifying files after they are written (which means that any network filesystem automatically breathes a huge sign of relief), but part of it is that it always reads full files, and the layout is done so that it really actually _uses_ everything it reads. It also caches beautifully on a memory subsystem level, largely for the same reasons. - it doesn't use tons of directories. You say that "subdirectories with lots of files" is painful, but that's not really the whole story. A _deep_ directory structure tends to actually be worse in many ways, because it's much easier to optimize a flat directory structure than a deep one. In other words, git ends up making name hashing etc _productive_. So yes, it's a bit wasteful. But it's wasteful of what is absolutely the cheapest resource around: disk space. It's not a huge downside, and in fact I really do believe that the biggest downside _by_far_ in diskspace utilization is the _seek_ costs, not the space itself. Let's face it, anybody who wants three years of kernel archives and thinks that 3GB of disk is too much, has some serious problems. 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. In seeking, the real cost is synchronization, and the git model actually means that there are very few seeks that have to be synchronized. You could literally do the "ls-tree" thing and make an absolutely trivial prefetcher that did the prefetching with enough parallellism that the filesystem could probably get decent IO performance out of a disk. In other words, we really could have a "git prefetch" command that would populate the cache of the current head quite efficiently. Because the data layout supports that. Linus - To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] Make -p flag optional from commit-tree.
We cannot currently say:
$ commit-tree $(write-tree) $(cat .git/heads/junio .git/heads/linus)
The above must be written as:
$ commit-tree $(write-tree) \
-p $(cat .git/heads/junio) \
-p $(cat .git/heads/linus)
This patch makes -p flag optional. Existing scripts are
hopefully not affected because they are passing -p properly. If
we want to introduce non parent-ID parameters to commit-tree
later, we can give them their own -flag letters.
Signed-off-by: Junio C Hamano <[EMAIL PROTECTED]>
---
commit-tree.c | 15 +++
1 files changed, 11 insertions(+), 4 deletions(-)
commit-tree.c: c0b07f89286c3f6cceae8122b4c3142c8efaf8e1
--- a/commit-tree.c
+++ b/commit-tree.c
@@ -297,10 +297,17 @@ int main(int argc, char **argv)
usage(commit_tree_usage);
check_valid(tree_sha1, "tree");
- for (i = 2; i < argc; i += 2) {
- char *a, *b;
- a = argv[i]; b = argv[i+1];
- if (!b || strcmp(a, "-p") || get_sha1_hex(b,
parent_sha1[parents]))
+ for (i = 2; i < argc; i++) {
+ /* Historically commit-tree required -p in front of
+* each parent commit ID. This is confusing. We can
+* add non parent commit ID parameter later by defining
+* flags other than "-p" so let's just ignore them.
+*/
+ if (! strcmp(argv[i], "-p"))
+ continue;
+
+ /* Currently it just expects parent IDs. */
+ if (get_sha1_hex(argv[i], parent_sha1[parents]))
usage(commit_tree_usage);
check_valid(parent_sha1[parents], "commit");
parents++;
-
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Colorized git log
Dear diary, on Thu, Apr 21, 2005 at 11:12:45PM CEST, I got a letter where Sean <[EMAIL PROTECTED]> told me that... > On the off chance that someone else might like it, here is a pager script > for the git log that adds a splash of color: Actually, I would've never expected that I would like it, but we all sometimes surprise ourselves. I made git log colorized if you pass it -c in current git-pasky. Thanks. -- Petr "Pasky" Baudis Stuff: http://pasky.or.cz/ C++: an octopus made by nailing extra legs onto a dog. -- Steve Taylor - To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: wit 0.0.3 - a web interface for git available
On 4/21/05, Kay Sievers <[EMAIL PROTECTED]> wrote: > On Wed, Apr 20, 2005 at 10:42:53AM +0100, Christoph Hellwig wrote: > > It's working now: > http://ehlo.org/~kay/gitweb.pl > Kay + Christian + Ken, That looks really great!. One suggestion: when drilling down through the tree it would be nice if the context of the parents could be dragged along too. So, for example, when displaying the BLOB, you could display its name because you have kept enough context around to allow that. This would also allow you to extend the functionality so that when you are at the BLOB level you could navigate to a history of changes to just that BLOB, at least from the point of view of the commit that got you there. Also, have you considered generating pure XML from the database and relying on XSLT (either at the server, or preferably at the client - they all do it well these days!) to do the HTML rendering? jon. - To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Linux 2.6.12-rc3
Hi! > > It seems that someone should write "Kernel hacker's guide to > > git"... Documentation/git.txt seems like good place. I guess I'll do > > it. > > I've also started writing some tutorial-like guide to Cogito on my > notebook, but I have time for that only during lectures. :^) Well, this will be really short and really kernel oriented. > > > I'm not yet sure if we should have some Cogito interface for doing this > > > and what its semantics should be. > > > > What is Cogito, BTW? > > New name for git-pasky. Everyone will surely rejoice as the usage will > change significantly. But better let's clean it up now. > > (For more details, check git@ archives for git-pasky-0.6 > announcement.) I liked git, and git-pasky did not seem too wrong, either... I did google search for cogito, and there are several companies named that way, and some are software-related. git was bad name, but cogito seems bad, too. I'd stick with git. Pavel -- Boycott Kodak -- for their patent abuse against Java. - To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Colorized git log
On the off chance that someone else might like it, here is a pager script for the git log that adds a splash of color: #!/bin/sh git log "$@" | sed -re ' /.*signed-off-by.*/Is//\x1b[34m&\x1b[0m/ /^--*$/Is//\x1b[31m&\x1b[0m/ /^(commit|tree|parent) .*/Is//\x1b[32m&\x1b[0m/ /^author .*/Is//\x1b[36m&\x1b[0m/ /^committer .*/Is//\x1b[35m&\x1b[0m/' | less -R Sean - To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: git-viz tool for visualising commit trees
* Olivier Andrieu <[EMAIL PROTECTED]> wrote: > > - naming the boxes by key is quite meaningless. It would be more > > informative to see the author's email shortcuts in the boxes. Also, it > > would be nice to see some simple graphical feedback about the size and > > scope of a changeset, without having to zoom on it. > > That's interesting. What do you mean exactly by scope ? usually there are two interesting things about a patchset: how many lines does it change, and how many files. Patches that change lots of files (but change only a couple of lines in every file) have a 'large' scope. Patches that change 1-2 files have a 'small' scope. A pure 'number of lines changed' metric is useful too. Generally patches that have either a large linecount or a large scope are more interesting. (I'm not sure how this could be displayed - perhaps the size of the rectangle could vary to a certain degree? Perhaps the shape too? Something non-numeric, so that one gets immediate visual feedback.) > > i guess you know it, and i'm definitely not complaining about prototype > > code, but rendering is quite slow: drawing the 340 changesets in the > > current kernel repository takes 15 seconds on a 2 GHz P4. Drawing the > > full kernel history (63,000 changesets) would take more than 45 minutes > > on this box. > > > > the current rate of kernel development is ~2000 changesets per month, so > > drawing the kernel history will get 3 seconds slower every day - it will > > exceed 1 minute in 20 days, so this will become a pressing issue quite > > soon i suspect. > > Right, it is slow. From what I could understand with a bit of > profiling, the problem is with the "text" canvas item for the boxes' > labels. I guess libgnomecanvas isn't using Pango properly or > something: it lookups the font with fontconfig each time I create such > an item. I'm not sure what I can do about this. when the redrawing happens in the visible area then one can see how really slow it is: 100-200 msec per rectangle (!). > It works with Petr Baudis' git-pasky (it calls `git diff'). I don't > know how to do that with the canonical git. ah, ok. I guess it will start working once Petr's changes are merged into Linus' tree. Ingo - To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [3/5] Add http-pull
On Wed, 20 Apr 2005, Brad Roberts wrote: > How about fetching in the inverse order. Ie, deepest parents up towards > current. With that method the repository is always self consistent, even > if not yet current. Daniel Barkalow replied: > You don't know the deepest parents to fetch until you've read everything > more recent, since the history you'd have to walk is the history you're > downloading. You "just" need to defer adding tree/commit objects to the repository until after you have inserted all objects on which they depend. That's what my "wget" based version does ... it's very crude, in that it loads all tree & commit objects into a temporary repository (.gittmp) ... since you can only use "cat-file" and "ls-tree" on things if they live in objects/xx/xxx..xxx The blobs can go directly into the real repo (but to be really safe you'd have to ensure that the whole blob had been pulled from the network before inserting it ... it's probably a good move to validate everything that you pull from the outside world too). -Tony - To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Pasky problem with 'git init URL'
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Am Donnerstag, 21. April 2005 23:15 schrieb John Stoffel: > > "Petr" == Petr Baudis <[EMAIL PROTECTED]> writes: > > Petr> Perhaps it would be useful to have some "command classes" (with at > least Petr> cg-*-(add|ls|rm)), like: > > Petr> cg-branch-ls > Petr> cg-remote-rm > Petr> cg-tag-add > > Just speaking of consistency, can we make it so that all the commands > are just variations with out the damm dashes in them? I think the dashes are especially useful, because of "tab-completion". > git[ ...] > I think thats exactly like above: cg-- cu Fabian -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.4 (GNU/Linux) iD8DBQFCaCHbI0lSH7CXz7MRAuSXAJ40v4yNgS13BIExfYTwPv8zbj2HcACdG7G6 YiLFD8u8Guh3xppaa14uD+I= =dkN/ -END PGP SIGNATURE- - To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [Gnu-arch-users] Re: [GNU-arch-dev] [ANNOUNCEMENT] /Arch/ embraces `git'
> However you're > right that the original structure proposed by Linus is too flat. That was the only point I *meant* to defend. The rest was error. -t - To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [Gnu-arch-users] Re: [GNU-arch-dev] [ANNOUNCEMENT] /Arch/ embraces `git'
> Tom, please stop this ext* filesystem bashing ;-) For one thing... yes, i'm totally embarassed on this issue. I made a late-night math error in a spec. *hopefully* would have noticed it on my own as I coded to that spec but y'all have been wonderful at pointing out my mistake to me even though I initially defended it. As for ext* bashing it's not bashing exactly. I/O bandwidth gets a little better, disks get a bunch cheaper --- then ext* doesn't look bad at all in this respect. And we're awefully close to that point. Meanwhile, for times measured in years, I've gotten complaints from ext* users about software that is just fine on other filesystems over issues like the allocation size of small files. So ext*, from my perspective, was a little too far ahead of its time and, yes, my complaints about it are just about reaching their expiration date. Anyway, thanks for all the sanity about directory layout. Really, it was just an "I'm too sleepy to be doing this right now" error. -t - To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Linux 2.6.12-rc3
Dear diary, on Thu, Apr 21, 2005 at 11:38:11PM CEST, I got a letter where Pavel Machek <[EMAIL PROTECTED]> told me that... > Hi! > > It seems that someone should write "Kernel hacker's guide to > git"... Documentation/git.txt seems like good place. I guess I'll do > it. I've also started writing some tutorial-like guide to Cogito on my notebook, but I have time for that only during lectures. :^) > > I'm not yet sure if we should have some Cogito interface for doing this > > and what its semantics should be. > > What is Cogito, BTW? New name for git-pasky. Everyone will surely rejoice as the usage will change significantly. But better let's clean it up now. (For more details, check git@ archives for git-pasky-0.6 announcement.) > > > I see quite a lot of problems with fsck-tree. Is that normal? > > > (I ran out of disk space few times during different operations...) > > > > Actually, in case your tree is older than about two days, I hope you did > > the convert-cache magic or fetched a fresh tree? > > No, I did not anything like that. I guess it is rm -rf time, then... That's the root of all your problems then. -- Petr "Pasky" Baudis Stuff: http://pasky.or.cz/ C++: an octopus made by nailing extra legs onto a dog. -- Steve Taylor - To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Linux 2.6.12-rc3
Hi! It seems that someone should write "Kernel hacker's guide to git"... Documentation/git.txt seems like good place. I guess I'll do it. > > just plain vanilla" without rm -rf? > > git cancel will give you "plain last commit". If you need plain vanilla, > the "hard way" now is to just do > > commit-id >.git/HEAD > > but your current HEAD will be lost forever. Or do > > git fork vanilla ~/vanilla linus > > and you will have the vanilla tree tracking linus in ~/vanilla. Ok, thanks. > I'm not yet sure if we should have some Cogito interface for doing this > and what its semantics should be. What is Cogito, BTW? > > I see quite a lot of problems with fsck-tree. Is that normal? > > (I ran out of disk space few times during different operations...) > > Actually, in case your tree is older than about two days, I hope you did > the convert-cache magic or fetched a fresh tree? No, I did not anything like that. I guess it is rm -rf time, then... Pavel -- Boycott Kodak -- for their patent abuse against Java. - To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Pasky problem with 'git init URL'
Dear diary, on Thu, Apr 21, 2005 at 11:15:54PM CEST, I got a letter where John Stoffel <[EMAIL PROTECTED]> told me that... > > "Petr" == Petr Baudis <[EMAIL PROTECTED]> writes: > > Petr> Perhaps it would be useful to have some "command classes" (with at least > Petr> cg-*-(add|ls|rm)), like: > > Petr> cg-branch-ls > Petr> cg-remote-rm > Petr> cg-tag-add > > Does a standard like: > > git[ ...] Isn't this basically what I was proposing? (Modulo the UI changes related to git-pasky -> Cogito.) -- Petr "Pasky" Baudis Stuff: http://pasky.or.cz/ C++: an octopus made by nailing extra legs onto a dog. -- Steve Taylor - To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] Docs update
Dear diary, on Thu, Apr 21, 2005 at 11:16:11PM CEST, I got a letter where David Greaves <[EMAIL PROTECTED]> told me that... > Petr Baudis wrote: > > > >Make a choice - either you are describing git or Cogito. The frmer has > >no RSYNC_FLAGS and does not care about any heads or anything at all (you > >might mention it as a recommended convention, though). > > I was going to do both - surely that's OK? I thought the original goal for README.reference was to be git-specific, and I planned to therefore push it to the core git at some point. I actually probably don't mind as long as you keep the two separated cleanly inside of the file, so if we shall want to include it in git, the trimming of the docs to only relevant parts is simple enough. -- Petr "Pasky" Baudis Stuff: http://pasky.or.cz/ C++: an octopus made by nailing extra legs onto a dog. -- Steve Taylor - To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] Docs update
Petr Baudis wrote: Make a choice - either you are describing git or Cogito. The frmer has no RSYNC_FLAGS and does not care about any heads or anything at all (you might mention it as a recommended convention, though). I was going to do both - surely that's OK? The only reason it's core so far is that I started working my way through the code alphabetically (having no other clue where to start!) As it turns out it will probably make sense to do all the core first - but I don't want to miss things so as I read through all the mails and extract content, I make a note of things like environment variables which I'll bulk up and cross reference later. I may even change my mind and make notes on Cogito if that takes my fancy too ;) I know it's not polished yet - but I'd rather publish it and have people catch mistakes. David - To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Pasky problem with 'git init URL'
> "Petr" == Petr Baudis <[EMAIL PROTECTED]> writes: Petr> Perhaps it would be useful to have some "command classes" (with at least Petr> cg-*-(add|ls|rm)), like: Petr> cg-branch-ls Petr> cg-remote-rm Petr> cg-tag-add Just speaking of consistency, can we make it so that all the commands are just variations with out the damm dashes in them? Something like: git lsbranch git lstag ... Or something mildly along those lines. I don't even care what ORDER they are, whether the 'ls' comes before or after the object type it works on. But make it the same every where, so that ls, rm, add, check, foo, barzle, ... all use the same format. Makes it much much easier to extrapolate what command syntax to use when new objects to be acted upon are added. Does a standard like: git[ ...] make sense? Easy to script, easy to remember. Even munging into a single word is ok. John - To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Pasky problem with 'git init URL'
On Thu, 2005-04-21 at 22:29 +0200, Petr Baudis wrote:
> Dear diary, on Thu, Apr 21, 2005 at 06:21:58PM CEST, I got a letter
> where Martin Schlemmer <[EMAIL PROTECTED]> told me that...
> > Hi,
>
> Hi,
>
> > Just pulled linux-2.6.git, and got this:
> >
> >
> > New branch: 3a6fd752a50af92765853879f4a11cc0cfcd0320
> > Tracked branch, applying changes...
> > Merging 4d78b6c78ae6d87e4c1c8072f42efa716f04afb9 ->
> > 3a6fd752a50af92765853879f4a11cc0cfcd0320
> > to a2755a80f40e5794ddc20e00f781af9d6320fafb...
> >
> > Enter commit message, terminated by ctrl-D on a separate line:
> > Merge with 3a6fd752a50af92765853879f4a11cc0cfcd0320
> >
> >
> > Weird thing was that I made no changes.
>
> did you compensate for the renamed hashes? Didn't you before update from
> some very old git-pasky version?
>
> Actually, did you do that git init _after_ the unsuccessful pull, or
> before?
>
I re-pulled it from scratch after the sha1 changes, so not that. Just
the next pull that went wonky.
> > Digging a bit deeper, I saw that .git/HEAD was a symlink
> > to .git/heads/master, and the tracked branch was 'origin'. Due to the
> > fact that Linus only have a .git/heads/master on his rsync, and this
> > thus updated to the new sha1, but the 'origin' (and tracked) head is
> > still pointing to an older sha1 caused this confusion.
>
> Duh. The remote branch always grabs the HEAD over there; you don't need
> to care about the various branches over there, and you really do not
> *want* to care. Actually I might add some ^branchname to the rsync URL,
> to be able to refer to particular branches inside of the repository.
>
Well, I just did a quick peek. I thought it just changed the local head
to the sha1 of the remote, and then updated the local files - haven't
yet looked at gitmerge.sh.
> > I replicated the linux tree via:
> >
> >
> > git init URL
> >
> >
> > So I had a look at gitinit.sh, which first creates the .git/heads/master
> > and symlinks HEAD to it, then on seeing a URL was supplied, creates
> > a .git/heads/origin, track it, but do *not* change the .git/HEAD
> > symlink ... Is this intended? I see also that gittrack.sh do not update
> > the HEAD symlink ... Is this also intended?
>
> Yes.
>
> You never work directly on the remote branch. Ever. That's what this
> tracking stuff is for; you set up a local branch which follows the
> remote one.
>
Ok, but for some weird reason it wanted to commit the merge between
remote and local.
> Otherwise, you fork to two trees, one is remote branch, second is local
> branch, and you do git pull remotebranch in the second. You are in
> trouble now. Also, if you do some local commit on the remote branch,
> what would happen? This kind of stuff is why I decided that you just
> cannot work on remote branches directly.
>
> > The last option however brings a problem or two. First, how do you do
> > the multi-head thing? Maybe add a command 'git lsheads' (and while at
> > it, also add 'git lstags'?)? Secondly, if there was more than one head,
>
> Perhaps it would be useful to have some "command classes" (with at least
> cg-*-(add|ls|rm)), like:
>
> cg-branch-ls
> cg-remote-rm
> cg-tag-add
>
Might make things more sane.
> > the local copy needs to be checked out ... don't know if 'git cancel' is
> > the logical thing the user will think to do ('git clone' perhaps?) ...
>
> I don't know what do you mean here.
>
Don't worry, no biggy.
--
Martin Schlemmer
signature.asc
Description: This is a digitally signed message part
Re: [PATCH] Docs update
Dear diary, on Thu, Apr 21, 2005 at 10:40:44PM CEST, I got a letter where David Greaves <[EMAIL PROTECTED]> told me that... > @@ -156,3 +317,23 @@ > unpack-file > unpack-file.c > > + > + > +git Environment Variables > +GIT_CACHE_DIRECTORY > +AUTHOR_NAME > +AUTHOR_EMAIL > +AUTHOR_DATE > +RSYNC_FLAGS > +GIT_INDEX_FILE > + > + > +.git Repository Files > + > +.git/HEAD > +This file always contains the last (head) commit object created for this > branch of the repository. > +(Usually symlinked to a file in .git/heads/) > + > +.git/heads/ > +This directory contains a file for each branch of the .git repository. > +The name of the file is the friendly name of the branch (eg pasky) Make a choice - either you are describing git or Cogito. The frmer has no RSYNC_FLAGS and does not care about any heads or anything at all (you might mention it as a recommended convention, though). -- Petr "Pasky" Baudis Stuff: http://pasky.or.cz/ C++: an octopus made by nailing extra legs onto a dog. -- Steve Taylor - To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] Add "git push"
Dear diary, on Thu, Apr 21, 2005 at 02:43:33PM CEST, I got a letter where Matthias Urlichs <[EMAIL PROTECTED]> told me that... > This patch adds the ability to "git push", as the obvious converse of > "git pull". While lack of locking is a problem for git-pasky too, for this git push it is a downright disaster waiting to happen. It might be also a good idea to check for remote 'blocked' file, which must exist and contain only a "pushtree" line. This is so that no (sensible) real working tree is attached to it, which would be a disaster for it too. You probably don't want to allow pushing if your local tree is blocked. And you want to allow pushing only when HEAD is your ancestor. (Helper tool wanted for this - we need this in git merge badly too.) BTW, it contains some unrelated and seemingly irrelevant tracking stuff. -- Petr "Pasky" Baudis Stuff: http://pasky.or.cz/ C++: an octopus made by nailing extra legs onto a dog. -- Steve Taylor - To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] Docs update
Added commit-tree, diff-cache and environment info Signed-off-by: David Greaves <[EMAIL PROTECTED]> --- Index: README.reference === --- c0260bfb82da04aeff4e598ced5295d6ae2e262d/README.reference (mode:100644 sha1:8186a561108d3c62625614272bd5e2f7d5826b4b) +++ 5f204110aef2538fdc512e09e4a075b3afac8eff/README.reference (mode:100644 sha1:b5fc4fb969ec3f52877408c8df4ba131a8c4a7b2) @@ -109,12 +109,173 @@ commit-tree - commit-tree [-p ]* < changelog + commit-tree [-p ...] < changelog +Creates a new commit object based on the provided tree object and +emits the new commit object id on stdout. If no parent is given then +it is considered to be an initial tree. + +A commit object usually has 1 parent (a commit after a change) or 2 +parents (a merge) although there is no reason it cannot have more than +2 parents. + +While a tree represents a particular directory state of a working +directory, a commit represents that state in "time", and explains how +to get there. + +Normally a commit would identify a new "HEAD" state, and while git +doesn't care where you save the note about that state, in practice we +tend to just write the result to the file ".git/HEAD", so that we can +always see what the last committed state was. + +Options + + + An existing tree object + +-p + Each -p indicates a the id of a parent commit object. + + +Commit Information + +A commit encapsulates: + all parent object ids + author name, email and date + committer name and email and the commit time. + +If not provided, commit-tree uses your name, hostname and domain to +provide author and committer info. This can be overridden using the +following environment variables. + AUTHOR_NAME + AUTHOR_EMAIL + AUTHOR_DATE + COMMIT_AUTHOR_NAME + COMMIT_AUTHOR_EMAIL +(nb <,> and CRs are stripped) + +A commit comment is read from stdin (max 999 chars) + +see also: write-tree + + + +diff-cache + diff-cache [-r] [-z] + +Compares the content and mode of the blobs found via a tree object +with the content of the current cache and, optionally, the stat state +of the file on disk. + +(This is basically a special case of diff-tree that works with the +current cache as the first tree.) + + + The id of a tree or commit object to diff against. + +-r + recurse + +-z + /0 line termintation on output + +--cached + do not consider the on-disk file at all + +Output format: + +For files in the tree but not in the cache +- + +For files in the cache but not in the tree ++ + +For files that differ: +*-> -> path/ + +In the special case of the file being changed on disk and out of sync with the cache, the sha1 + +Operating Modes +You can choose whether you want to trust the index file entirely +(using the "--cached" flag) or ask the diff logic to show any files +that don't match the stat state as being "tentatively changed". Both +of these operations are very useful indeed. + +Cached Mode +If --cached is specified, it allows you to ask: + show me the differences between HEAD and the current index + contents (the ones I'd write with a "write-tree") + +For example, let's say that you have worked on your index file, and are +ready to commit. You want to see eactly _what_ you are going to commit is +without having to write a new tree object and compare it that way, and to +do that, you just do + + diff-cache --cached $(cat .git/HEAD) + +Example: let's say I had renamed "commit.c" to "git-commit.c", and I had +done an "upate-cache" to make that effective in the index file. +"show-diff" wouldn't show anything at all, since the index file matches +my working directory. But doing a diff-cache does: + [EMAIL PROTECTED]:~/git> diff-cache --cached $(cat .git/HEAD) + -100644 blob4161aecc6700a2eb579e842af0b7f22b98443f74commit.c + +100644 blob4161aecc6700a2eb579e842af0b7f22b98443f74 git-commit.c + +And as you can see, the output matches "diff-tree -r" output (we +always do "-r", since the index is always fully populated +??CHECK??). +You can trivially see that the above is a rename. + +In fact, "diff-tree --cached" _should_ always be entirely equivalent to +actually doing a "write-tree" and comparing that. Except this one is much +nicer for the case where you just want to check where you are. + +So doing a "diff-cache --cached" is basically very useful when you are +asking yourself "what have I already marked for being committed, and +what's the difference to a previous tree". + +Non-cached Mode + +The "non-cached" mode takes a different approach, and is potentially +the even more useful of the two in that what it does can't be emulated +with a "write-tree + diff-tree". Thus that's the default mode.
Re: [Gnu-arch-users] Re: [GNU-arch-dev] [ANNOUNCEMENT] /Arch/ embraces `git'
> [your 0:3/4:7 directory hierarchy is horked] Absolutely. Made a dumb mistake the night I wrote that spec and embarassed that I initially defended it. I had an arithmetic error. Thanks, this time, for your persistence in pointing it out. -t - To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [Gnu-arch-users] Re: [GNU-arch-dev] [ANNOUNCEMENT] /Arch/ embraces `git'
> Yes, it really doesn't make much sense to have so big keys on the > directories. It's official... i'm blushing wildly thank you for the various replies that pointed out my thinko. That part of my spec hasn't been coded yet --- i just wrote text. It really was the silly late-night error of sort: "hmm...let's see, 4 hex digits plus 4 hex digits that's 16 bits sounds about right." Really, I'll fix it. -t - To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Pasky problem with 'git init URL'
Dear diary, on Thu, Apr 21, 2005 at 06:21:58PM CEST, I got a letter
where Martin Schlemmer <[EMAIL PROTECTED]> told me that...
> Hi,
Hi,
> Just pulled linux-2.6.git, and got this:
>
>
> New branch: 3a6fd752a50af92765853879f4a11cc0cfcd0320
> Tracked branch, applying changes...
> Merging 4d78b6c78ae6d87e4c1c8072f42efa716f04afb9 ->
> 3a6fd752a50af92765853879f4a11cc0cfcd0320
> to a2755a80f40e5794ddc20e00f781af9d6320fafb...
>
> Enter commit message, terminated by ctrl-D on a separate line:
> Merge with 3a6fd752a50af92765853879f4a11cc0cfcd0320
>
>
> Weird thing was that I made no changes.
did you compensate for the renamed hashes? Didn't you before update from
some very old git-pasky version?
Actually, did you do that git init _after_ the unsuccessful pull, or
before?
> Digging a bit deeper, I saw that .git/HEAD was a symlink
> to .git/heads/master, and the tracked branch was 'origin'. Due to the
> fact that Linus only have a .git/heads/master on his rsync, and this
> thus updated to the new sha1, but the 'origin' (and tracked) head is
> still pointing to an older sha1 caused this confusion.
Duh. The remote branch always grabs the HEAD over there; you don't need
to care about the various branches over there, and you really do not
*want* to care. Actually I might add some ^branchname to the rsync URL,
to be able to refer to particular branches inside of the repository.
> I replicated the linux tree via:
>
>
> git init URL
>
>
> So I had a look at gitinit.sh, which first creates the .git/heads/master
> and symlinks HEAD to it, then on seeing a URL was supplied, creates
> a .git/heads/origin, track it, but do *not* change the .git/HEAD
> symlink ... Is this intended? I see also that gittrack.sh do not update
> the HEAD symlink ... Is this also intended?
Yes.
You never work directly on the remote branch. Ever. That's what this
tracking stuff is for; you set up a local branch which follows the
remote one.
Otherwise, you fork to two trees, one is remote branch, second is local
branch, and you do git pull remotebranch in the second. You are in
trouble now. Also, if you do some local commit on the remote branch,
what would happen? This kind of stuff is why I decided that you just
cannot work on remote branches directly.
> The last option however brings a problem or two. First, how do you do
> the multi-head thing? Maybe add a command 'git lsheads' (and while at
> it, also add 'git lstags'?)? Secondly, if there was more than one head,
Perhaps it would be useful to have some "command classes" (with at least
cg-*-(add|ls|rm)), like:
cg-branch-ls
cg-remote-rm
cg-tag-add
> the local copy needs to be checked out ... don't know if 'git cancel' is
> the logical thing the user will think to do ('git clone' perhaps?) ...
I don't know what do you mean here.
--
Petr "Pasky" Baudis
Stuff: http://pasky.or.cz/
C++: an octopus made by nailing extra legs onto a dog. -- Steve Taylor
-
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] multi item packed files
On Thursday 21 April 2005 15:28, Krzysztof Halasa wrote: > Linus Torvalds <[EMAIL PROTECTED]> writes: > > Wrong. You most definitely _can_ lose: you end up having to optimize for > > one particular filesystem blocking size, and you'll lose on any other > > filesystem. And you'll lose on the special filesystem of "network > > traffic", which is byte-granular. > > If someone needs better on-disk ratio, (s)he can go with 1 KB filesystem > or something like that, without all the added complexity of packing. > > If we want to optimize that further, I would try doing it at the > underlying filesystem level. For example, loop-mounted one. 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've got: 1) subdirectories with lots of files 2) wasted space for tiny files 3) files that are likely to be accessed together spread across the whole disk One compromise for SCM use would be one packed file per commit, with an index that lets us quickly figure out which commit has a particular version of a given file. My hack gets something close to that (broken into 32k chunks for no good reason), and the index to find a given file is just the git directory tree. But my code does hide the fact that we're packing things from most of the git interfaces. So I can almost keep a straight face while claiming to be true to the original git design...almost. The whole setup is far from perfect, but it is one option for addressing points 2 & 3 above. -chris - To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: git-viz tool for visualising commit trees
> Ingo Molnar [Thu, 21 Apr 2005]: > I just checked how the kernel repository looks like with it, and > i'm impressed! The GUI is top-notch, and the whole graph output and > navigation is very mature visually. Kudos! Thanks ! > - there doesnt seem to be any performance difference between non-colored > and colored rendering - so you might as well want to make 'color by > author' (or color by branch) the default coloring, instead of > uncolored? It has to call `cat-file commit' for each commit id to get the author ... it's just that's a lot of forks. > - naming the boxes by key is quite meaningless. It would be more > informative to see the author's email shortcuts in the boxes. Also, it > would be nice to see some simple graphical feedback about the size and > scope of a changeset, without having to zoom on it. That's interesting. What do you mean exactly by scope ? > i guess you know it, and i'm definitely not complaining about prototype > code, but rendering is quite slow: drawing the 340 changesets in the > current kernel repository takes 15 seconds on a 2 GHz P4. Drawing the > full kernel history (63,000 changesets) would take more than 45 minutes > on this box. > > the current rate of kernel development is ~2000 changesets per month, so > drawing the kernel history will get 3 seconds slower every day - it will > exceed 1 minute in 20 days, so this will become a pressing issue quite > soon i suspect. Right, it is slow. From what I could understand with a bit of profiling, the problem is with the "text" canvas item for the boxes' labels. I guess libgnomecanvas isn't using Pango properly or something: it lookups the font with fontconfig each time I create such an item. I'm not sure what I can do about this. Also, there's a -noaa option that draws an non-antialiased canvas : it's noticeably faster (and uglier too). > Ingo Molnar [Thu, 21 Apr 2005]: > another thing, when i 'zoom out' of the graph far away (so that the > whole graph becomes visible on the screen), i'm getting lots of such > error messages: > > *** attempt to put segment in horiz list twice Yes, this message must come from one of the libraries (libart most probably) > Ingo Molnar [Thu, 21 Apr 2005]: > is the 'diff with ancestor' feature supposed to work at this early > stage? (it just does nothing when i click on it. It correctly > offers two ancestors for merge points, but does nothing there > either.) It works with Petr Baudis' git-pasky (it calls `git diff'). I don't know how to do that with the canonical git. Thanks for the suggestions, -- Olivier - To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] multi item packed files
On Thu, 21 Apr 2005, Krzysztof Halasa wrote: > > If someone needs better on-disk ratio, (s)he can go with 1 KB filesystem > or something like that, without all the added complexity of packing. I really think the argument that "you can use filesystem feature XYZ" is bogus. I know that I'm not willing to switch filesystems on a whim. I suspect nobody else is either. I'm not going to create a loopback filesystem just for git, it's just too much pain. And dammit, if I'm the original author and likely biggest power-user, and _I_ can't be bothered to use special filesystems, then who can? Nobody. This is why I absolutely do not believe in arguments like "if your filesystem doesn't do tail packing, you shouldn't use it" or "if your don't have name hashing enabled in your filesystem it's broken". I'm perfectly willing to optimize for the common case, but that's as far as it goes. I do not want to make fundamental design decisions that depend on the target filesystem having some particular feature. (I'll happily make decisions that say that the target _OS_ has to have a particular feature, though. I'll require a sane base-level for functionality, but not something like filesystem details). Linus - To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] Allow "git cancel" to change branches
Hi, Matthias! On Thu, 2005-04-21 at 23:31 +1000, Matthias Urlichs wrote: > "git cancel" may not be named correctly for this job, but it does almost > everything you'd need for switching between one branch and another > within a repository, so... This functionality is badly needed, but "git cancel" should probably remain what it is. > +if [ "$1" ] ; then > + test -f .git/heads/$1 || cp .git/HEAD .git/heads/$1 > + ln -sf "heads/$1" .git/HEAD > +fi Considering that the patch is essentially just this block of code, it could be (in the first approximation) a separate command, e.g. "git switch", that would call "git cancel" if needed. But let's consider the fact that "git cancel" removes all local changes. That's quite a serious side effect. I don't always want to remove local changes when I switch between branches in CVS. Many users would prefer git to do a merge. I think that "git track" needs to be redesigned. There are at least three properties of the working directory (related to branch tracking) that users may want to change: 1) Where new revisions are pulled from. It could be more than one branch (ideal implementation - with several copies of rsync run simultaneously). 2) What branch is "checked out" to the working directory, i.e. what branch would "git cancel" restore. 3) Whether new changes are merged automatically. I suggest following syntax: git track -b WORKING-BRANCH [--cancel] [--active|--passive] [TRACK-BRANCH...|--notrack] --cancel would cancel changes rather than merge when the current branch changes. --active enables automerge, --passive disables it Empty list of branches to track should not disable tracking. Only --notrack should do it. Then your "git cancel BRANCH" would become: git track -b BRANCH --cancel -- Regards, Pavel Roskin - To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
[RFC] A suggestion for more versatile naming conventios in the object database
In the transition from git-0.04 to git-0.5 (Linus' track) the naming
convention of files in the object database has been changed: a file's
name passed from the sha1 of its contents to the sha1 of its contents
*before* compression.
This change was preceded by a long discussion hence both conventions
have arguments for and against.
I would like to suggest to adopt a more versatile solution:
preserve the pure sha1 based names for the sha1 sum of the file's
contents. I mean,
(*) for files with name xy/z{38} their sha1 sum is xyz{38}
allow other files (or links) with names of the form
xy/z{38}.EXTENSION
where for every EXTENSION the file's content would be the EXTENSION
representation of the file xy/z{38} . For every representation type
EXTENSION there should be procedures to derive the file xy/z{38}
from the name xy/z{38}.EXTENSION and vice-versa (assuming that the
representation type EXTENSION cares about the contents of file
xy/z{38}).
Let me give two examples:
all the files in the object database of git-0.04 are just fine, they
satisfy axiom (*)
the name of every file xy/z{38} in the git-0.5 data base should be
changed to xy/z{38}.g assuming that we will use EXTENSION g as the
git representation type. The conversion algorithms would be:
cat-file `cat-file -t xyz{38}` xyz{38} to obtain the contents
represented by xy/z{38}.g whose sha1 is xyz{38}
and a utility program has to be written to check whether a given
file F, is a valid contents as far as git is concerned and in
case it is compute its sha1 sum xyz{38} and also comute the file
the file xy/z{38}.g .
So, what are the advantages of this further complication? I see these ones:
git is separated from the idea of sha1 addressable contents, which
indeed is an idea larger than git itself. This same or similar
addressing schemes can (and most probably will) be applied to other
contents besides SCMs. An example would be a digital library of
scientific papers in pdf together with its OAI compliant meta data
(don't bother if you are not familiar with these terms, it is just
an example and I am sure you are able to come up with many other
examples where a sha1 addressable data base would be interesting)
all these uses could share common backup schemes where axiom (*)
would be enforced. One could think of a shared p2p database of
repositories of sha1 addressed contents of all kinds. This might be
important because, in general, the contents of xyz{38} cannot be
reconstructed from its name. The way to defend against file system
corruption is replication. Why not share these backup databases?
it would be easier to experiment with other compression schemes or
other proposals for meta data in git itself.
it would be easier to experiment with the factorization of common
chunks of contents, an idea very close to the secret of rsync's
amazing efficiency.
Well, that's the proposal. I would be happy to hear comments!
Cheers,
Imre Simon
PS: the way it is, the git-0.5 README file is inconsistent. The naming
change is not reflected in the README file which in many places states
that the sha1 sum of file xy/z{38} is xyz{38}.
-
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Mozilla SHA1 implementation
I've just integrated the Mozilla SHA1 library implementation that Adgar Toernig sent me into the standard git archive (but I did the integration differently). The Mozilla SHA1 code is copyright Paul Kocher and Cryptography Research, and is released under a dual MPL/GPL license. Git obviously uses it in the GPL version, but I left the MPL choice there too, so that those two files (that are in a subdirectory of its own) will continue to be dual-licensed. NOTE! I left git using the openssl libraries by default, and this is a built-time choice in the makefile. You can choose the Mozilla SHA1 implementation by doing make clean MOZILLA_SHA1=1 make make install but I suspect that anybody that has openssl installed and is working on an x86 is much better off with the i586-optimized openssl version. But if you don't have openssl by default, or if you don't like openssl for some other reason, you now have a nice easy choice. Interestingly, the Mozilla SHA1 code is about twice as fast as the openssl code on my G5, and judging by the disassembly, it's because it's much simpler. I think the openssl people have unrolled all the loops totally, which tends to be a disaster on any half-way modern CPU. But hey, it could be something as simple as optimization flags too. Linus - To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] #!/bin/sh --> #!/usr/bin/env bash
On Thu, Apr 21, 2005 at 10:31:02PM +0800, Alecs King wrote: > On Thu, Apr 21, 2005 at 12:23:26PM +0200, Klaus Robert Suetterlin wrote: > > Hi, > > > > I supply a patch that dehardcodes the path to bash (which is not /bin > > on all computers) and adds sys/limits.h to provide ULONG_MAX. > > Hi, i did a similar patch a while back ago. As for ULONG_MAX, not every > sytem has , i think is the rite place to go. > > The patch below tested on both debian and fbsd. > > [snip] And as for bash, only gitdiff-do and gitlog.sh 'explicitly' use bash instead of /bin/sh. On most Linux distros, /bin/sh is just a symbolic link to bash. But not on some others. I found gitlsobj.sh could not work using a plain /bin/sh on fbsd. To make life easier, i think it might be better if we all explicitly use bash for all shell scripts. patch below assumes the patch above has been applied. commit 341cd1241815178d567ce612c97c2bb5a663021a tree abb16c39fe8354383b632f7fa9dd4611ff66e1d1 parent 2deea74db72fb57a8b80e7945f23814112b22723 author Alecs King 1114107613 +0800 committer Alecs King 1114107613 +0800 Explicitly use bash #!/bin/sh ==> #!/usr/bin/env bash Index: gitXlntree.sh === --- 0c92ac3af53457b6b9651cf82d98ce3a7b166dcd/gitXlntree.sh (mode:100755 sha1:c474913d09906739d8175f1b430720a3ac67e798) +++ abb16c39fe8354383b632f7fa9dd4611ff66e1d1/gitXlntree.sh (mode:100755 sha1:adc01eeb56f394a6168ae1f6f1fe4c40e1c2aecc) @@ -1,4 +1,4 @@ -#!/bin/sh +#!/usr/bin/env bash # # Provide an independent view to the objects database. # Copyright (c) Petr Baudis, 2005 Index: gitXnormid.sh === --- 0c92ac3af53457b6b9651cf82d98ce3a7b166dcd/gitXnormid.sh (mode:100755 sha1:c0d53afabe8662ebfc3c697faf08b0a2b43c93f7) +++ abb16c39fe8354383b632f7fa9dd4611ff66e1d1/gitXnormid.sh (mode:100755 sha1:9b311aca57bd8b7012f45d730c6fd26d5fb5d2b2) @@ -1,4 +1,4 @@ -#!/bin/sh +#!/usr/bin/env bash # # Internal: Normalize the given ID to a tree ID. # Copyright (c) Petr Baudis, 2005 Index: gitadd.sh === --- 0c92ac3af53457b6b9651cf82d98ce3a7b166dcd/gitadd.sh (mode:100755 sha1:3f5e9a2d6b452d596cd853f1585113bdb356a2e3) +++ abb16c39fe8354383b632f7fa9dd4611ff66e1d1/gitadd.sh (mode:100755 sha1:6feb7372e95be4546af17e0c6b55d10c9a1c441d) @@ -1,4 +1,4 @@ -#!/bin/sh +#!/usr/bin/env bash # # Add new file to a GIT repository. # Copyright (c) Petr Baudis, 2005 Index: gitaddremote.sh === --- 0c92ac3af53457b6b9651cf82d98ce3a7b166dcd/gitaddremote.sh (mode:100755 sha1:a117b9e8d14b977143caa48c26fc51794e8b7135) +++ abb16c39fe8354383b632f7fa9dd4611ff66e1d1/gitaddremote.sh (mode:100755 sha1:bccaa9068063b07d13012477861c6706b7cd40a6) @@ -1,4 +1,4 @@ -#!/bin/sh +#!/usr/bin/env bash # # Add new "remote" to the GIT repository. # Copyright (c) Petr Baudis, 2005 Index: gitapply.sh === --- 0c92ac3af53457b6b9651cf82d98ce3a7b166dcd/gitapply.sh (mode:100755 sha1:7703809dc0743c6e4c1fa5b7d922a4efc16b4276) +++ abb16c39fe8354383b632f7fa9dd4611ff66e1d1/gitapply.sh (mode:100755 sha1:794ea5ed6acdd34e34742a17cbd784dcbf738289) @@ -1,4 +1,4 @@ -#!/bin/sh +#!/usr/bin/env bash # # Apply a diff generated by git diff. # Copyright (c) Petr Baudis, 2005 Index: gitcancel.sh === --- 0c92ac3af53457b6b9651cf82d98ce3a7b166dcd/gitcancel.sh (mode:100755 sha1:74b4083d67eda87d88a6f92c6c66877bba8bda8a) +++ abb16c39fe8354383b632f7fa9dd4611ff66e1d1/gitcancel.sh (mode:100755 sha1:c320ee98e2ed0b13a68de3b2ec4e4a8451b5189a) @@ -1,4 +1,4 @@ -#!/bin/sh +#!/usr/bin/env bash # # Cancels current edits in the working tree. # Copyright (c) Petr Baudis, 2005 Index: gitcommit.sh === --- 0c92ac3af53457b6b9651cf82d98ce3a7b166dcd/gitcommit.sh (mode:100755 sha1:a13bef2c84492ed75679d7d52bb710df35544f8a) +++ abb16c39fe8354383b632f7fa9dd4611ff66e1d1/gitcommit.sh (mode:100755 sha1:0207f402cc5107de2a4685f6fcade081c41d91e9) @@ -1,4 +1,4 @@ -#!/bin/sh +#!/usr/bin/env bash # # Commit into a GIT repository. # Copyright (c) Petr Baudis, 2005 Index: gitdiff.sh === --- 0c92ac3af53457b6b9651cf82d98ce3a7b166dcd/gitdiff.sh (mode:100755 sha1:8e14a868f513f4ec524a2c8974c8d202c6824038) +++ abb16c39fe8354383b632f7fa9dd4611ff66e1d1/gitdiff.sh (mode:100755 sha1:e27915d4172717ddd4d01269877312b08ed2acc4) @@ -1,4 +1,4 @@ -#!/bin/sh +#!/usr/bin/env bash # # Make a diff between two GIT trees. # Copyright (c) Petr Baudis, 2005 Index: gitexport.sh === --- 0c92ac3af53457b6b9651cf82d98ce3a7b166dcd/gitexport.sh (mode:100755 sha1:5b94424beca55ffe6b5535e4
Re: [PATCH] multi item packed files
Linus Torvalds <[EMAIL PROTECTED]> writes: > Wrong. You most definitely _can_ lose: you end up having to optimize for > one particular filesystem blocking size, and you'll lose on any other > filesystem. And you'll lose on the special filesystem of "network > traffic", which is byte-granular. If someone needs better on-disk ratio, (s)he can go with 1 KB filesystem or something like that, without all the added complexity of packing. If we want to optimize that further, I would try doing it at the underlying filesystem level. For example, loop-mounted one. -- Krzysztof Halasa - To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Linux 2.6.12-rc3
Dear diary, on Thu, Apr 21, 2005 at 09:00:09PM CEST, I got a letter where Pavel Machek <[EMAIL PROTECTED]> told me that... > Hi! Hi, > > > Well, not sure. > > > > > > I did > > > > > > git track linus > > > git cancel > > > > > > but Makefile still contains -rc2. (Is "git cancel" right way to check > > > out the tree?) > > > > No. git cancel does what it says - cancels your local changes to the > > working tree. git track will only set that next time you pull from > > linus, the changes will be automatically merged. (Note that this will > > change with the big UI change.) > > Is there way to say "forget those changes in my repository, I want > just plain vanilla" without rm -rf? git cancel will give you "plain last commit". If you need plain vanilla, the "hard way" now is to just do commit-id >.git/HEAD but your current HEAD will be lost forever. Or do git fork vanilla ~/vanilla linus and you will have the vanilla tree tracking linus in ~/vanilla. I'm not yet sure if we should have some Cogito interface for doing this and what its semantics should be. > I see quite a lot of problems with fsck-tree. Is that normal? > (I ran out of disk space few times during different operations...) Actually, in case your tree is older than about two days, I hope you did the convert-cache magic or fetched a fresh tree? -- Petr "Pasky" Baudis Stuff: http://pasky.or.cz/ C++: an octopus made by nailing extra legs onto a dog. -- Steve Taylor - To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [Gnu-arch-users] Re: [GNU-arch-dev] [ANNOUNCEMENT] /Arch/ embraces `git'
> Using your suggested indexing method that uses [0:4] as the 1st level key and [0:3] > [4:8] as the 2nd level key, I obtain an indexed archive that occupies 159M, > where the top level contains 18665 1st level keys, the largest first level dir > contains 5 entries, and all 2nd level dirs contain exactly 1 entry. That's just a mistake in the spec. The format should probably be multi-level but, yes, the fanout I suggested is currently quite bogus. When I write that part of that code (today or tomorrow) I'll fix it. A few people pointed that out. Thanks. -t - To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 01-19/19] All of the above combined
Make the cache management code behave more like a library. There are no
longer any global variables in read-cache.c. Nothing ever uses more than
one cache yet, but I can see how it might simplify some of the merge code.
Signed-off-by: Brad Roberts <[EMAIL PROTECTED]>
---
cache.h | 36 +++--
check-files.c| 12 +--
checkout-cache.c | 22 +++---
diff-cache.c | 36 -
merge-cache.c| 29 ---
read-cache.c | 200 ---
read-tree.c | 71 +++
show-diff.c | 19 +++--
show-files.c | 27 +++
update-cache.c | 39 +-
write-tree.c | 24 +++---
11 files changed, 292 insertions(+), 223 deletions(-)
Index: cache.h
===
--- c0260bfb82da04aeff4e598ced5295d6ae2e262d/cache.h (mode:100644
sha1:828d660ab82bb35a1ca632a2ba4620dc483889bd)
+++ 38adb888a4c1adfe083f24d4ec51018e0b5a8335/cache.h (mode:100644
sha1:d8ade9f4b9bd9b6045f97b4df5bef8356c767d46)
@@ -17,21 +17,6 @@
#include
/*
- * Basic data structures for the directory cache
- *
- * NOTE NOTE NOTE! This is all in the native CPU byte format. It's
- * not even trying to be portable. It's trying to be efficient. It's
- * just a cache, after all.
- */
-
-#define CACHE_SIGNATURE 0x44495243 /* "DIRC" */
-struct cache_header {
- unsigned int hdr_signature;
- unsigned int hdr_version;
- unsigned int hdr_entries;
-};
-
-/*
* The "cache_time" is just the low 32 bits of the
* time. It doesn't matter if it overflows - we only
* check it for equality in the 32 bits we save.
@@ -67,6 +52,8 @@
#define CE_STAGEMASK (0x3000)
#define CE_STAGESHIFT 12
+extern int ce_match_stat(struct cache_entry *ce, struct stat *st);
+
#define create_ce_flags(len, stage) htons((len) | ((stage) << CE_STAGESHIFT))
#define ce_namelen(ce) (CE_NAMEMASK & ntohs((ce)->ce_flags))
#define ce_size(ce) cache_entry_size(ce_namelen(ce))
@@ -78,8 +65,6 @@
#define cache_entry_size(len) ((offsetof(struct cache_entry,name) + (len) + 8)
& ~7)
const char *sha1_file_directory;
-struct cache_entry **active_cache;
-unsigned int active_nr, active_alloc;
#define DB_ENVIRONMENT "SHA1_FILE_DIRECTORY"
#define DEFAULT_DB_ENVIRONMENT ".git/objects"
@@ -87,12 +72,17 @@
#define alloc_nr(x) (((x)+16)*3/2)
/* Initialize and use the cache information */
-extern int read_cache(void);
-extern int write_cache(int newfd, struct cache_entry **cache, int entries);
-extern int cache_name_pos(const char *name, int namelen);
-extern int add_cache_entry(struct cache_entry *ce, int ok_to_add);
-extern int remove_file_from_cache(char *path);
-extern int cache_match_stat(struct cache_entry *ce, struct stat *st);
+extern struct cache *new_cache(void);
+extern struct cache *read_cache(void);
+extern int write_cache(struct cache *cache, int newfd);
+extern void free_cache(struct cache *cache);
+extern int cache_name_pos(struct cache *cache, const char *name, int namelen);
+extern int add_cache_entry(struct cache *cache, struct cache_entry *ce, int
ok_to_add);
+extern int remove_file_from_cache(struct cache *cache, char *path);
+extern int get_num_cache_entries(struct cache *cache);
+extern struct cache_entry * get_cache_entry(struct cache *cache, int pos);
+extern void set_cache_entry(struct cache *cache, struct cache_entry *ce, int
pos);
+extern int remove_cache_entry_at(struct cache *cache, int pos);
#define MTIME_CHANGED 0x0001
#define CTIME_CHANGED 0x0002
Index: check-files.c
===
--- c0260bfb82da04aeff4e598ced5295d6ae2e262d/check-files.c (mode:100644
sha1:7d16691aa9d51b5b4670d5837b3527ee7c7da79c)
+++ 38adb888a4c1adfe083f24d4ec51018e0b5a8335/check-files.c (mode:100644
sha1:4de6d39e4997d29f13261c21eeb378f74b3f8a8f)
@@ -8,7 +8,7 @@
*/
#include "cache.h"
-static void check_file(const char *path)
+static void check_file(struct cache *cache, const char *path)
{
int fd = open(path, O_RDONLY);
struct cache_entry *ce;
@@ -23,15 +23,15 @@
}
/* Exists but is not in the cache is not fine */
- pos = cache_name_pos(path, strlen(path));
+ pos = cache_name_pos(cache, path, strlen(path));
if (pos < 0)
die("preparing to update existing file '%s' not in cache",
path);
- ce = active_cache[pos];
+ ce = get_cache_entry(cache, pos);
if (fstat(fd, &st) < 0)
die("fstat(%s): %s", path, strerror(errno));
- changed = cache_match_stat(ce, &st);
+ changed = ce_match_stat(ce, &st);
if (changed)
die("preparing to update file '%s' not uptodate in cache",
path);
}
@@ -39,9 +39,9 @@
int main(int argc, char **argv)
{
int i;
+ struct cache *cache = read_cache();
- read_cache();
for (i = 1; i < argc ; i++)
- check_file(argv[i]);
+
[PATCH 19/19] the end goal of the last dozen or so commits, there's no longer a global cache variable
tree 38adb888a4c1adfe083f24d4ec51018e0b5a8335
parent 0a556dc01b8e48f684ce6e0c26f8c00b5e39c4ac
author Brad Roberts <[EMAIL PROTECTED]> 1114093024 -0700
committer Brad Roberts <[EMAIL PROTECTED]> 1114093024 -0700
[PATCH] the end goal of the last dozen or so commits, there's no longer a
global cache variable
Signed-off-by: Brad Roberts <[EMAIL PROTECTED]>
---
cache.h | 21 +++---
check-files.c| 10 +++---
checkout-cache.c | 20 ++---
diff-cache.c | 20 ++---
merge-cache.c| 29 ++-
read-cache.c | 82 ---
read-tree.c | 51 ++
show-diff.c |8 ++---
show-files.c | 27 +-
update-cache.c | 35 ---
write-tree.c | 20 ++---
11 files changed, 167 insertions(+), 156 deletions(-)
Index: cache.h
===
--- 0a556dc01b8e48f684ce6e0c26f8c00b5e39c4ac:1/cache.h (mode:100644
sha1:c64969602d80a0e9d7137b2716fb808c912b075c)
+++ 7e396358c12c0129bcb4945e3e35a4fa76890a0c:1/cache.h (mode:100644
sha1:d8ade9f4b9bd9b6045f97b4df5bef8356c767d46)
@@ -72,16 +72,17 @@
#define alloc_nr(x) (((x)+16)*3/2)
/* Initialize and use the cache information */
-extern int read_cache(void);
-extern int write_cache(int newfd);
-extern void free_cache();
-extern int cache_name_pos(const char *name, int namelen);
-extern int add_cache_entry(struct cache_entry *ce, int ok_to_add);
-extern int remove_file_from_cache(char *path);
-extern int get_num_cache_entries();
-extern struct cache_entry * get_cache_entry(int pos);
-extern void set_cache_entry(struct cache_entry *ce, int pos);
-extern int remove_cache_entry_at(int pos);
+extern struct cache *new_cache(void);
+extern struct cache *read_cache(void);
+extern int write_cache(struct cache *cache, int newfd);
+extern void free_cache(struct cache *cache);
+extern int cache_name_pos(struct cache *cache, const char *name, int namelen);
+extern int add_cache_entry(struct cache *cache, struct cache_entry *ce, int
ok_to_add);
+extern int remove_file_from_cache(struct cache *cache, char *path);
+extern int get_num_cache_entries(struct cache *cache);
+extern struct cache_entry * get_cache_entry(struct cache *cache, int pos);
+extern void set_cache_entry(struct cache *cache, struct cache_entry *ce, int
pos);
+extern int remove_cache_entry_at(struct cache *cache, int pos);
#define MTIME_CHANGED 0x0001
#define CTIME_CHANGED 0x0002
Index: check-files.c
===
--- 0a556dc01b8e48f684ce6e0c26f8c00b5e39c4ac:1/check-files.c (mode:100644
sha1:0973e81fbbc0f9f98031fb249254bd89d809)
+++ 7e396358c12c0129bcb4945e3e35a4fa76890a0c:1/check-files.c (mode:100644
sha1:4de6d39e4997d29f13261c21eeb378f74b3f8a8f)
@@ -8,7 +8,7 @@
*/
#include "cache.h"
-static void check_file(const char *path)
+static void check_file(struct cache *cache, const char *path)
{
int fd = open(path, O_RDONLY);
struct cache_entry *ce;
@@ -23,10 +23,10 @@
}
/* Exists but is not in the cache is not fine */
- pos = cache_name_pos(path, strlen(path));
+ pos = cache_name_pos(cache, path, strlen(path));
if (pos < 0)
die("preparing to update existing file '%s' not in cache",
path);
- ce = get_cache_entry(pos);
+ ce = get_cache_entry(cache, pos);
if (fstat(fd, &st) < 0)
die("fstat(%s): %s", path, strerror(errno));
@@ -39,9 +39,9 @@
int main(int argc, char **argv)
{
int i;
+ struct cache *cache = read_cache();
- read_cache();
for (i = 1; i < argc ; i++)
- check_file(argv[i]);
+ check_file(cache, argv[i]);
return 0;
}
Index: checkout-cache.c
===
--- 0a556dc01b8e48f684ce6e0c26f8c00b5e39c4ac:1/checkout-cache.c (mode:100644
sha1:27b559d5bcc5831eda441bcd1fd88d687f2567b8)
+++ 7e396358c12c0129bcb4945e3e35a4fa76890a0c:1/checkout-cache.c (mode:100644
sha1:2e8c61323a72f6052d8c9ef76a4eef05aa5ac0f9)
@@ -120,23 +120,23 @@
return write_entry(ce);
}
-static int checkout_file(const char *name)
+static int checkout_file(struct cache *cache, const char *name)
{
- int pos = cache_name_pos(name, strlen(name));
+ int pos = cache_name_pos(cache, name, strlen(name));
if (pos < 0) {
if (!quiet)
fprintf(stderr, "checkout-cache: %s is not in the
cache\n", name);
return -1;
}
- return checkout_entry(get_cache_entry(pos));
+ return checkout_entry(get_cache_entry(cache, pos));
}
-static int checkout_all(void)
+static int checkout_all(struct cache *cache)
{
int i;
- for (i = 0; i < get_num_cache_entries() ; i++) {
- struct cache_entry *ce
[PATCH 18/19] rename cache_match_stat to ce_match_stat to match other cache_entry related functions/macros
tree f8dd454f774d42526149193970b612a46f3ddd26
parent 058c25fd81e5949354d96f2aad222ae73a6c1dee
author Brad Roberts <[EMAIL PROTECTED]> 1114088345 -0700
committer Brad Roberts <[EMAIL PROTECTED]> 1114088345 -0700
[PATCH] rename cache_match_stat to ce_match_stat to match other cache_entry
related functions/macros
Signed-off-by: Brad Roberts <[EMAIL PROTECTED]>
---
cache.h |3 ++-
check-files.c|2 +-
checkout-cache.c |2 +-
diff-cache.c |2 +-
read-cache.c |2 +-
show-diff.c |2 +-
update-cache.c |2 +-
7 files changed, 8 insertions(+), 7 deletions(-)
Index: cache.h
===
--- 058c25fd81e5949354d96f2aad222ae73a6c1dee:1/cache.h (mode:100644
sha1:a3018f9e12bfdd1a5273b20fcab5062667c6caec)
+++ 0a556dc01b8e48f684ce6e0c26f8c00b5e39c4ac:1/cache.h (mode:100644
sha1:c64969602d80a0e9d7137b2716fb808c912b075c)
@@ -52,6 +52,8 @@
#define CE_STAGEMASK (0x3000)
#define CE_STAGESHIFT 12
+extern int ce_match_stat(struct cache_entry *ce, struct stat *st);
+
#define create_ce_flags(len, stage) htons((len) | ((stage) << CE_STAGESHIFT))
#define ce_namelen(ce) (CE_NAMEMASK & ntohs((ce)->ce_flags))
#define ce_size(ce) cache_entry_size(ce_namelen(ce))
@@ -76,7 +78,6 @@
extern int cache_name_pos(const char *name, int namelen);
extern int add_cache_entry(struct cache_entry *ce, int ok_to_add);
extern int remove_file_from_cache(char *path);
-extern int cache_match_stat(struct cache_entry *ce, struct stat *st);
extern int get_num_cache_entries();
extern struct cache_entry * get_cache_entry(int pos);
extern void set_cache_entry(struct cache_entry *ce, int pos);
Index: check-files.c
===
--- 058c25fd81e5949354d96f2aad222ae73a6c1dee:1/check-files.c (mode:100644
sha1:919e418b5f0f85220445c876a37bf4cf61d26525)
+++ 0a556dc01b8e48f684ce6e0c26f8c00b5e39c4ac:1/check-files.c (mode:100644
sha1:0973e81fbbc0f9f98031fb249254bd89d809)
@@ -31,7 +31,7 @@
if (fstat(fd, &st) < 0)
die("fstat(%s): %s", path, strerror(errno));
- changed = cache_match_stat(ce, &st);
+ changed = ce_match_stat(ce, &st);
if (changed)
die("preparing to update file '%s' not uptodate in cache",
path);
}
Index: checkout-cache.c
===
--- 058c25fd81e5949354d96f2aad222ae73a6c1dee:1/checkout-cache.c (mode:100644
sha1:bf9cd0572c883219d37f2788ec5f5553a136df2b)
+++ 0a556dc01b8e48f684ce6e0c26f8c00b5e39c4ac:1/checkout-cache.c (mode:100644
sha1:27b559d5bcc5831eda441bcd1fd88d687f2567b8)
@@ -100,7 +100,7 @@
struct stat st;
if (!stat(ce->name, &st)) {
- unsigned changed = cache_match_stat(ce, &st);
+ unsigned changed = ce_match_stat(ce, &st);
if (!changed)
return 0;
if (!force) {
Index: diff-cache.c
===
--- 058c25fd81e5949354d96f2aad222ae73a6c1dee:1/diff-cache.c (mode:100644
sha1:548211944fc00594bfc06b9ab90f0cb476688285)
+++ 0a556dc01b8e48f684ce6e0c26f8c00b5e39c4ac:1/diff-cache.c (mode:100644
sha1:5ae6d5de5ed5ad34f72267904ff8eb6288855fc5)
@@ -125,7 +125,7 @@
show_file("-", path1, mode1, sha1, base);
return -1;
}
- changed = cache_match_stat(ce, &st);
+ changed = ce_match_stat(ce, &st);
close(fd);
if (changed) {
mode2 = st.st_mode;
Index: read-cache.c
===
--- 058c25fd81e5949354d96f2aad222ae73a6c1dee:1/read-cache.c (mode:100644
sha1:31e293a3686622c9ec180d41aa37d85ce49325e8)
+++ 0a556dc01b8e48f684ce6e0c26f8c00b5e39c4ac:1/read-cache.c (mode:100644
sha1:8837d27ab683bf07d38aee33c62a90f5a7221588)
@@ -44,7 +44,7 @@
cache = NULL;
}
-int cache_match_stat(struct cache_entry *ce, struct stat *st)
+int ce_match_stat(struct cache_entry *ce, struct stat *st)
{
unsigned int changed = 0;
Index: show-diff.c
===
--- 058c25fd81e5949354d96f2aad222ae73a6c1dee:1/show-diff.c (mode:100644
sha1:6e04e9182667cbb79afa4c878a31b685fdea3229)
+++ 0a556dc01b8e48f684ce6e0c26f8c00b5e39c4ac:1/show-diff.c (mode:100644
sha1:4a0902f50b3120b7791a4d4627a9a4f729afdcf7)
@@ -193,7 +193,7 @@
}
continue;
}
- changed = cache_match_stat(ce, &st);
+ changed = ce_match_stat(ce, &st);
if (!changed)
continue;
if (!machine_readable)
Index: update-cache.c
===
--- 058c25fd81e5949354d96f2aad222ae73a6c1dee:1/update-cache.c (mode:100644
sha1:83
[PATCH 17/19] temporarily change add_cache_entry to create an empty cache on demand
tree 6feaeb314fb1bea393250972b109b7d218cf37d7
parent b965055600b8bf4927ea631446cd6cde714aef95
author Brad Roberts <[EMAIL PROTECTED]> 1114087949 -0700
committer Brad Roberts <[EMAIL PROTECTED]> 1114087949 -0700
[PATCH] temporarily change add_cache_entry to create an empty cache on demand
read-tree.c expects to be able to add entries into an empty cache in the
non-merging mode.
Signed-off-by: Brad Roberts <[EMAIL PROTECTED]>
---
read-cache.c | 26 ++
1 files changed, 18 insertions(+), 8 deletions(-)
Index: read-cache.c
===
--- b965055600b8bf4927ea631446cd6cde714aef95:1/read-cache.c (mode:100644
sha1:c399f8e497441147afe630ca080558a8c6c79c78)
+++ 058c25fd81e5949354d96f2aad222ae73a6c1dee:1/read-cache.c (mode:100644
sha1:31e293a3686622c9ec180d41aa37d85ce49325e8)
@@ -32,6 +32,18 @@
static struct cache * cache = NULL;
+struct cache * new_cache()
+{
+ return (struct cache*)calloc(1, sizeof(struct cache));
+}
+
+void free_cache()
+{
+ munmap(cache->map.ptr, cache->map.size);
+ free(cache);
+ cache = NULL;
+}
+
int cache_match_stat(struct cache_entry *ce, struct stat *st)
{
unsigned int changed = 0;
@@ -155,6 +167,11 @@
{
int pos;
+ /* temporary, read-tree.c expects the cache to always exist, even
+* without a read_cache being called */
+ if (!cache)
+ cache = new_cache();
+
pos = cache_name_pos(ce->name, htons(ce->ce_flags));
/* existing match? Just replace it */
@@ -230,7 +247,7 @@
return (errno == ENOENT) ? 0 : error("open failed");
errno = ENOMEM;
- cache = (struct cache*)malloc(sizeof(struct cache));
+ cache = new_cache();
if (!cache)
return error("unable to allocate cache");
@@ -333,10 +350,3 @@
}
return ce_flush(&c, newfd);
}
-
-void free_cache()
-{
- munmap(cache->map.ptr, cache->map.size);
- free(cache);
- cache = NULL;
-}
-
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 16/19] change all call sites that use the return value of read_cache to get the # of cache entries.
tree 6bce19032505c2939bf74eeca5e51aeefa4e1600
parent f07f7073f45a7f81e5b6cf26f5181e14fd051d81
author Brad Roberts <[EMAIL PROTECTED]> 1114086602 -0700
committer Brad Roberts <[EMAIL PROTECTED]> 1114086602 -0700
[PATCH] change all call sites that use the return value of read_cache to get
the # of cache entries.
This patch somewhat breaks error handling for those call sites. I'll fix
that in the next few patches.
Signed-off-by: Brad Roberts <[EMAIL PROTECTED]>
---
show-diff.c| 13 -
update-cache.c |3 ++-
write-tree.c |4 +++-
3 files changed, 13 insertions(+), 7 deletions(-)
Index: show-diff.c
===
--- f07f7073f45a7f81e5b6cf26f5181e14fd051d81:1/show-diff.c (mode:100644
sha1:e2642b65805b3e52a16c6309b44a92c2a2bd13c3)
+++ b965055600b8bf4927ea631446cd6cde714aef95:1/show-diff.c (mode:100644
sha1:6e04e9182667cbb79afa4c878a31b685fdea3229)
@@ -126,10 +126,17 @@
int silent_on_nonexisting_files = 0;
int machine_readable = 0;
int reverse = 0;
- int entries = read_cache();
+ int entries;
int matched = 0;
int i;
+ read_cache();
+ entries = get_num_cache_entries();
+ if (entries < 0) {
+ perror("read_cache");
+ exit(1);
+ }
+
while (1 < argc && argv[1][0] == '-') {
if (!strcmp(argv[1], "-R"))
reverse = 1;
@@ -147,10 +154,6 @@
/* At this point, if argc == 1, then we are doing everything.
* Otherwise argv[1] .. argv[argc-1] have the explicit paths.
*/
- if (entries < 0) {
- perror("read_cache");
- exit(1);
- }
prepare_diff_cmd();
for (i = 0; i < entries; i++) {
struct stat st;
Index: update-cache.c
===
--- f07f7073f45a7f81e5b6cf26f5181e14fd051d81:1/update-cache.c (mode:100644
sha1:e741f593eb9c56c596fabed7eb6b79dee2d8cba9)
+++ b965055600b8bf4927ea631446cd6cde714aef95:1/update-cache.c (mode:100644
sha1:8328975cb726f5e06a413a9f0099bfa2f81d3381)
@@ -299,7 +299,8 @@
atexit(remove_lock_file);
remove_lock = 1;
- entries = read_cache();
+ read_cache();
+ entries = get_num_cache_entries();
if (entries < 0)
die("cache corrupted");
Index: write-tree.c
===
--- f07f7073f45a7f81e5b6cf26f5181e14fd051d81:1/write-tree.c (mode:100644
sha1:f1b12cdde1bb446a134a121760007150008b251a)
+++ b965055600b8bf4927ea631446cd6cde714aef95:1/write-tree.c (mode:100644
sha1:92e707fd4780805da160ce6fa282e75111ea67b9)
@@ -101,9 +101,11 @@
int main(int argc, char **argv)
{
int i, unmerged;
- int entries = read_cache();
+ int entries;
unsigned char sha1[20];
+ read_cache();
+ entries = get_num_cache_entries();
if (entries <= 0)
die("write-tree: no cache contents to write");
-
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 15/19] introduce a cache struct and move the various cache globals into it.
tree c806c7328a6c9297df108ab00ebe1c4014496cb0
parent b7d4fa53d4ee449b4b9b4f3c9dd40d6c99db4bc1
author Brad Roberts <[EMAIL PROTECTED]> 1114086327 -0700
committer Brad Roberts <[EMAIL PROTECTED]> 1114086327 -0700
[PATCH] introduce a cache struct and move the various cache globals into it.
New elements in the cache struct that previously were discarded:
- the cache headers
- the mmap info so we can cleanup later
For this stage, the cache itself is still a global variable. That will change.
Signed-off-by: Brad Roberts <[EMAIL PROTECTED]>
---
cache.h |1
read-cache.c | 127 ++-
2 files changed, 76 insertions(+), 52 deletions(-)
Index: cache.h
===
--- b7d4fa53d4ee449b4b9b4f3c9dd40d6c99db4bc1:1/cache.h (mode:100644
sha1:74d6c4d25c564e08eadc04aaef31a711d0645a43)
+++ f07f7073f45a7f81e5b6cf26f5181e14fd051d81:1/cache.h (mode:100644
sha1:a3018f9e12bfdd1a5273b20fcab5062667c6caec)
@@ -72,6 +72,7 @@
/* Initialize and use the cache information */
extern int read_cache(void);
extern int write_cache(int newfd);
+extern void free_cache();
extern int cache_name_pos(const char *name, int namelen);
extern int add_cache_entry(struct cache_entry *ce, int ok_to_add);
extern int remove_file_from_cache(char *path);
Index: read-cache.c
===
--- b7d4fa53d4ee449b4b9b4f3c9dd40d6c99db4bc1:1/read-cache.c (mode:100644
sha1:b16a72dc4e4525a7df060b3a43722217db7869c2)
+++ f07f7073f45a7f81e5b6cf26f5181e14fd051d81:1/read-cache.c (mode:100644
sha1:c399f8e497441147afe630ca080558a8c6c79c78)
@@ -17,8 +17,20 @@
unsigned int hdr_entries;
};
-static struct cache_entry **active_cache = NULL;
-static unsigned int active_nr = 0, active_alloc = 0;
+struct mmap_holder {
+ void * ptr;
+ size_t size;
+};
+
+struct cache {
+ struct mmap_holder map;
+ struct cache_header *header;
+ struct cache_entry **entries;
+ unsigned int num_entries;
+ unsigned int allocated_entries;
+};
+
+static struct cache * cache = NULL;
int cache_match_stat(struct cache_entry *ce, struct stat *st)
{
@@ -81,10 +93,10 @@
int first, last;
first = 0;
- last = active_nr;
+ last = cache->num_entries;
while (last > first) {
int next = (last + first) >> 1;
- struct cache_entry *ce = active_cache[next];
+ struct cache_entry *ce = cache->entries[next];
int cmp = cache_name_compare(name, namelen, ce->name,
htons(ce->ce_flags));
if (!cmp)
return next;
@@ -100,10 +112,10 @@
/* Remove entry, return true if there are more entries to go.. */
int remove_cache_entry_at(int pos)
{
- active_nr--;
- if (pos >= active_nr)
+ cache->num_entries--;
+ if (pos >= cache->num_entries)
return 0;
- memmove(active_cache + pos, active_cache + pos + 1, (active_nr - pos) *
sizeof(struct cache_entry *));
+ memmove(cache->entries + pos, cache->entries + pos + 1,
(cache->num_entries - pos) * sizeof(struct cache_entry *));
return 1;
}
@@ -123,20 +135,20 @@
int get_num_cache_entries()
{
- return active_nr;
+ return cache->num_entries;
}
struct cache_entry * get_cache_entry(int pos)
{
- return active_cache[pos];
+ return cache->entries[pos];
}
void set_cache_entry(struct cache_entry *ce, int pos)
{
- /* You can NOT just free active_cache[i] here, since it
+ /* You can NOT just free cache->entries[i] here, since it
* might not be necessarily malloc()ed but can also come
* from mmap(). */
- active_cache[pos] = ce;
+ cache->entries[pos] = ce;
}
int add_cache_entry(struct cache_entry *ce, int ok_to_add)
@@ -147,7 +159,7 @@
/* existing match? Just replace it */
if (pos >= 0) {
- active_cache[pos] = ce;
+ cache->entries[pos] = ce;
return 0;
}
pos = -pos-1;
@@ -156,8 +168,8 @@
* Inserting a merged entry ("stage 0") into the index
* will always replace all non-merged entries..
*/
- if (pos < active_nr && ce_stage(ce) == 0) {
- while (same_name(active_cache[pos], ce)) {
+ if (pos < cache->num_entries && ce_stage(ce) == 0) {
+ while (same_name(cache->entries[pos], ce)) {
ok_to_add = 1;
if (!remove_cache_entry_at(pos))
break;
@@ -168,16 +180,16 @@
return -1;
/* Make sure the array is big enough .. */
- if (active_nr == active_alloc) {
- active_alloc = alloc_nr(active_alloc);
- active_cache = realloc(active_cache, active_alloc *
sizeof(struct cache_entry *));
+ if (cache->num_entries == cac
[PATCH 14/19] move cache_header out of the public view
tree a2c82ce3512904f82f78d87d86709a471f67ef9f
parent ff3667537379d5b0680e8c4f9a14d82dc9835430
author Brad Roberts <[EMAIL PROTECTED]> 1114083477 -0700
committer Brad Roberts <[EMAIL PROTECTED]> 1114083477 -0700
[PATCH] move cache_header out of the public view
Signed-off-by: Brad Roberts <[EMAIL PROTECTED]>
---
cache.h | 15 ---
read-cache.c | 11 +++
2 files changed, 11 insertions(+), 15 deletions(-)
Index: cache.h
===
--- ff3667537379d5b0680e8c4f9a14d82dc9835430:1/cache.h (mode:100644
sha1:b29bb0ca5e7be15c0b423101f5cf381ee68f139e)
+++ b7d4fa53d4ee449b4b9b4f3c9dd40d6c99db4bc1:1/cache.h (mode:100644
sha1:74d6c4d25c564e08eadc04aaef31a711d0645a43)
@@ -17,21 +17,6 @@
#include
/*
- * Basic data structures for the directory cache
- *
- * NOTE NOTE NOTE! This is all in the native CPU byte format. It's
- * not even trying to be portable. It's trying to be efficient. It's
- * just a cache, after all.
- */
-
-#define CACHE_SIGNATURE 0x44495243 /* "DIRC" */
-struct cache_header {
- unsigned int hdr_signature;
- unsigned int hdr_version;
- unsigned int hdr_entries;
-};
-
-/*
* The "cache_time" is just the low 32 bits of the
* time. It doesn't matter if it overflows - we only
* check it for equality in the 32 bits we save.
Index: read-cache.c
===
--- ff3667537379d5b0680e8c4f9a14d82dc9835430:1/read-cache.c (mode:100644
sha1:0e972a80fa19eb77fd547fb579354af784be3ac4)
+++ b7d4fa53d4ee449b4b9b4f3c9dd40d6c99db4bc1:1/read-cache.c (mode:100644
sha1:b16a72dc4e4525a7df060b3a43722217db7869c2)
@@ -6,6 +6,17 @@
#include
#include "cache.h"
+/*
+ * Basic data structures for the directory cache
+ */
+
+#define CACHE_SIGNATURE 0x44495243 /* "DIRC" */
+struct cache_header {
+ unsigned int hdr_signature;
+ unsigned int hdr_version;
+ unsigned int hdr_entries;
+};
+
static struct cache_entry **active_cache = NULL;
static unsigned int active_nr = 0, active_alloc = 0;
-
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 13/19] Remove active_cache, active_nr, and active_alloc from public view
tree 9198385d73b718a2fd016362a9d93ccce1e7423c
parent cc414a188c0e8fefa7bea4f969cc7adfe4265d6f
author Brad Roberts <[EMAIL PROTECTED]> 1114083132 -0700
committer Brad Roberts <[EMAIL PROTECTED]> 1114083132 -0700
[PATCH] Remove active_cache, active_nr, and active_alloc from public view
Signed-off-by: Brad Roberts <[EMAIL PROTECTED]>
---
cache.h |2 --
read-cache.c |4 ++--
2 files changed, 2 insertions(+), 4 deletions(-)
Index: cache.h
===
--- cc414a188c0e8fefa7bea4f969cc7adfe4265d6f:1/cache.h (mode:100644
sha1:74d816c34245e0dde41643188f38cf99ca75e75f)
+++ ff3667537379d5b0680e8c4f9a14d82dc9835430:1/cache.h (mode:100644
sha1:b29bb0ca5e7be15c0b423101f5cf381ee68f139e)
@@ -78,8 +78,6 @@
#define cache_entry_size(len) ((offsetof(struct cache_entry,name) + (len) + 8)
& ~7)
const char *sha1_file_directory;
-struct cache_entry **active_cache;
-unsigned int active_nr, active_alloc;
#define DB_ENVIRONMENT "SHA1_FILE_DIRECTORY"
#define DEFAULT_DB_ENVIRONMENT ".git/objects"
Index: read-cache.c
===
--- cc414a188c0e8fefa7bea4f969cc7adfe4265d6f:1/read-cache.c (mode:100644
sha1:286f7136bc164f3a2317bb492138d9221efb4025)
+++ ff3667537379d5b0680e8c4f9a14d82dc9835430:1/read-cache.c (mode:100644
sha1:0e972a80fa19eb77fd547fb579354af784be3ac4)
@@ -6,8 +6,8 @@
#include
#include "cache.h"
-struct cache_entry **active_cache = NULL;
-unsigned int active_nr = 0, active_alloc = 0;
+static struct cache_entry **active_cache = NULL;
+static unsigned int active_nr = 0, active_alloc = 0;
int cache_match_stat(struct cache_entry *ce, struct stat *st)
{
-
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 12/19] fix up diff-cache.c to use new cache api's
tree 44f1ef88a5d0effdf2337f4c72b88b2bdcd9a54b
parent 8a4556bdf5bc847117c840a8fd7fa42f6efb16e1
author Brad Roberts <[EMAIL PROTECTED]> 1114082996 -0700
committer Brad Roberts <[EMAIL PROTECTED]> 1114082996 -0700
[PATCH] fix up diff-cache.c to use new cache api's
Along the way, rewrite to use a position index rather than pointer math.
Signed-off-by: Brad Roberts <[EMAIL PROTECTED]>
---
diff-cache.c | 32 +---
1 files changed, 13 insertions(+), 19 deletions(-)
Index: diff-cache.c
===
--- 8a4556bdf5bc847117c840a8fd7fa42f6efb16e1:1/diff-cache.c (mode:100644
sha1:fcbc4900d32f4ca24f67bb8f0fe344c6c5642ac9)
+++ cc414a188c0e8fefa7bea4f969cc7adfe4265d6f:1/diff-cache.c (mode:100644
sha1:548211944fc00594bfc06b9ab90f0cb476688285)
@@ -4,7 +4,7 @@
static int recursive = 0;
static int line_termination = '\n';
-static int diff_cache(void *tree, unsigned long size, struct cache_entry **ac,
int entries, const char *base);
+static int diff_cache(void *tree, unsigned long size, int pos, const char
*base);
static void update_tree_entry(void **bufp, unsigned long *sizep)
{
@@ -82,10 +82,10 @@
}
static int compare_tree_entry(const char *path1, unsigned int mode1, const
unsigned char *sha1,
- struct cache_entry **ac, int *entries, const char
*base)
+ int *pos, const char *base)
{
int baselen = strlen(base);
- struct cache_entry *ce = *ac;
+ struct cache_entry *ce = get_cache_entry(*pos);
const char *path2 = ce->name + baselen;
unsigned int mode2 = ntohl(ce->ce_mode);
const unsigned char *sha2 = ce->sha1;
@@ -107,7 +107,7 @@
memcpy(newbase + baselen + pathlen1, "/", 2);
if (!tree || strcmp(type, "tree"))
die("unable to read tree object %s",
sha1_to_hex(sha1));
- *entries = diff_cache(tree, size, ac, *entries,
newbase);
+ *pos = diff_cache(tree, size, *pos, newbase);
free(newbase);
free(tree);
return -1;
@@ -158,7 +158,7 @@
return 0;
}
-static int diff_cache(void *tree, unsigned long size, struct cache_entry **ac,
int entries, const char *base)
+static int diff_cache(void *tree, unsigned long size, int pos, const char
*base)
{
int baselen = strlen(base);
@@ -167,15 +167,16 @@
unsigned int mode;
const char *path;
const unsigned char *sha1;
- int left;
/*
* No entries in the cache (with this base)?
* Output the tree contents.
*/
- if (!entries || ce_namelen(ce = *ac) < baselen ||
memcmp(ce->name, base, baselen)) {
+ if ((pos == get_num_cache_entries()) ||
+ ce_namelen(ce = get_cache_entry(pos)) < baselen ||
+ memcmp(ce->name, base, baselen)) {
if (!size)
- return entries;
+ return pos;
sha1 = extract(tree, size, &path, &mode);
show_file("-", path, mode, sha1, base);
update_tree_entry(&tree, &size);
@@ -187,27 +188,20 @@
*/
if (!size) {
show_file("+", ce->name, ntohl(ce->ce_mode), ce->sha1,
"");
- ac++;
- entries--;
+ pos++;
continue;
}
sha1 = extract(tree, size, &path, &mode);
- left = entries;
- switch (compare_tree_entry(path, mode, sha1, ac, &left, base)) {
+ switch (compare_tree_entry(path, mode, sha1, &pos, base)) {
case -1:
update_tree_entry(&tree, &size);
- if (left < entries) {
- ac += (entries - left);
- entries = left;
- }
continue;
case 0:
update_tree_entry(&tree, &size);
/* Fallthrough */
case 1:
- ac++;
- entries--;
+ pos++;
continue;
}
die("diff-cache: internal error");
@@ -263,5 +257,5 @@
if (strcmp(type, "tree"))
die("bad tree object %s (%s)", sha1_to_hex(tree_sha1), type);
- return diff_cache(tree, size, active_cache, active_nr, "");
+ return diff_cache(tree, size, 0, "");
}
-
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vge
[PATCH 11/19] migrate write-tree.c to use the new cache api's
tree 3a2928786f84d81cfb1a5846cdaf9f3d5403cbcf
parent a94803645fb68119be8835d466585c91e664a173
author Brad Roberts <[EMAIL PROTECTED]> 1114077713 -0700
committer Brad Roberts <[EMAIL PROTECTED]> 1114077713 -0700
[PATCH] migrate write-tree.c to use the new cache api's
Along the way, altered the write_tree recursion to stay based off of a starting
position rather than moving the array pointer for each recurse step.
Signed-off-by: Brad Roberts <[EMAIL PROTECTED]>
---
write-tree.c | 18 +-
1 files changed, 9 insertions(+), 9 deletions(-)
Index: write-tree.c
===
--- a94803645fb68119be8835d466585c91e664a173:1/write-tree.c (mode:100644
sha1:827809dbddbff6dd8cf842641f6db5ad2f3ae07a)
+++ 8a4556bdf5bc847117c840a8fd7fa42f6efb16e1:1/write-tree.c (mode:100644
sha1:f1b12cdde1bb446a134a121760007150008b251a)
@@ -29,7 +29,7 @@
#define ORIG_OFFSET (40) /* Enough space to add the header of "tree
\0" */
-static int write_tree(struct cache_entry **cachep, int maxentries, const char
*base, int baselen, unsigned char *returnsha1)
+static int write_tree(int start_pos, const char *base, int baselen, unsigned
char *returnsha1)
{
unsigned char subdir_sha1[20];
unsigned long size, offset;
@@ -43,7 +43,7 @@
nr = 0;
do {
- struct cache_entry *ce = cachep[nr];
+ struct cache_entry *ce = get_cache_entry(start_pos + nr);
const char *pathname = ce->name, *filename, *dirname;
int pathlen = ce_namelen(ce), entrylen;
unsigned char *sha1;
@@ -53,16 +53,13 @@
if (baselen >= pathlen || memcmp(base, pathname, baselen))
break;
- sha1 = ce->sha1;
- mode = ntohl(ce->ce_mode);
-
/* Do we have _further_ subdirectories? */
filename = pathname + baselen;
dirname = strchr(filename, '/');
if (dirname) {
int subdir_written;
- subdir_written = write_tree(cachep + nr, maxentries -
nr, pathname, dirname-pathname+1, subdir_sha1);
+ subdir_written = write_tree(start_pos + nr, pathname,
dirname-pathname+1, subdir_sha1);
nr += subdir_written;
/* Now we need to write out the directory entry into
this tree.. */
@@ -72,6 +69,9 @@
/* ..but the directory entry doesn't count towards the
total count */
nr--;
sha1 = subdir_sha1;
+ } else {
+ sha1 = ce->sha1;
+ mode = ntohl(ce->ce_mode);
}
if (check_valid_sha1(sha1) < 0)
@@ -87,7 +87,7 @@
memcpy(buffer + offset, sha1, 20);
offset += 20;
nr++;
- } while (nr < maxentries);
+ } while ((start_pos + nr) < get_num_cache_entries());
i = prepend_integer(buffer, offset - ORIG_OFFSET, ORIG_OFFSET);
i -= 5;
@@ -110,7 +110,7 @@
/* Verify that the tree is merged */
unmerged = 0;
for (i = 0; i < entries; i++) {
- struct cache_entry *ce = active_cache[i];
+ struct cache_entry *ce = get_cache_entry(i);
if (ntohs(ce->ce_flags) & ~CE_NAMEMASK) {
if (++unmerged > 10) {
fprintf(stderr, "...\n");
@@ -123,7 +123,7 @@
die("write-tree: not able to write tree");
/* Ok, write it out */
- if (write_tree(active_cache, entries, "", 0, sha1) != entries)
+ if (write_tree(0, "", 0, sha1) != entries)
die("write-tree: internal error");
printf("%s\n", sha1_to_hex(sha1));
return 0;
-
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 10/19] migrate check-files.c to the new cache api's
tree 54aca1a1c5f41995c79fdf6b5f720574d0bfd8ef
parent 50a6596bf7f51ecd598cd02d9c44379a9b92044a
author Brad Roberts <[EMAIL PROTECTED]> 1114077105 -0700
committer Brad Roberts <[EMAIL PROTECTED]> 1114077105 -0700
[PATCH] migrate check-files.c to the new cache api's
Signed-off-by: Brad Roberts <[EMAIL PROTECTED]>
---
check-files.c |2 +-
1 files changed, 1 insertion(+), 1 deletion(-)
Index: check-files.c
===
--- 50a6596bf7f51ecd598cd02d9c44379a9b92044a:1/check-files.c (mode:100644
sha1:7d16691aa9d51b5b4670d5837b3527ee7c7da79c)
+++ a94803645fb68119be8835d466585c91e664a173:1/check-files.c (mode:100644
sha1:919e418b5f0f85220445c876a37bf4cf61d26525)
@@ -26,7 +26,7 @@
pos = cache_name_pos(path, strlen(path));
if (pos < 0)
die("preparing to update existing file '%s' not in cache",
path);
- ce = active_cache[pos];
+ ce = get_cache_entry(pos);
if (fstat(fd, &st) < 0)
die("fstat(%s): %s", path, strerror(errno));
-
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 09/19] migrate read-tree.c to the new cache api's
tree 7a3cab4437a849857cc899017b97eea1787a6ce1
parent 099367f98cc063c33733d15c7a2d9737bea853d9
author Brad Roberts <[EMAIL PROTECTED]> 1114077044 -0700
committer Brad Roberts <[EMAIL PROTECTED]> 1114077044 -0700
[PATCH] migrate read-tree.c to the new cache api's
Signed-off-by: Brad Roberts <[EMAIL PROTECTED]>
---
read-tree.c | 52 +++-
1 files changed, 31 insertions(+), 21 deletions(-)
Index: read-tree.c
===
--- 099367f98cc063c33733d15c7a2d9737bea853d9:1/read-tree.c (mode:100644
sha1:4ad48f5c409ead69407d2b5feab4466cdcb499f8)
+++ 50a6596bf7f51ecd598cd02d9c44379a9b92044a:1/read-tree.c (mode:100644
sha1:ad9128f26613a82361475516dd0f2b470f4ce4b3)
@@ -146,26 +146,30 @@
return NULL;
}
-static void trivially_merge_cache(struct cache_entry **src, int nr)
+/* rather than doing the 'right' thing of deleting entries as we merge,
+ * walk dst through the cache, overwriting entries as we go and at the
+ * end truncate the size of the cache */
+static void trivially_merge_cache()
{
static struct cache_entry null_entry;
- struct cache_entry **dst = src;
struct cache_entry *old = &null_entry;
+ int src = 0, dst = 0, nr = get_num_cache_entries();
- while (nr) {
+ while (src < nr) {
struct cache_entry *ce, *result;
- ce = src[0];
+ ce = get_cache_entry(src);
/* We throw away original cache entries except for the stat
information */
if (!ce_stage(ce)) {
old = ce;
src++;
- nr--;
- active_nr--;
continue;
}
- if (nr > 2 && (result = merge_entries(ce, src[1], src[2])) !=
NULL) {
+ if ((src < (nr - 2)) &&
+ (result = merge_entries(ce,
+ get_cache_entry(src + 1),
+ get_cache_entry(src + 2))) != NULL)
{
/*
* See if we can re-use the old CE directly?
* That way we get the uptodate stat info.
@@ -175,40 +179,46 @@
ce = result;
ce->ce_flags &= ~htons(CE_STAGEMASK);
src += 2;
- nr -= 2;
- active_nr -= 2;
}
- *dst++ = ce;
+ set_cache_entry(ce, dst);
+ dst++;
src++;
+ }
+ /* this could be replaced by a truncate api */
+ while (nr > dst) {
nr--;
+ remove_cache_entry_at(nr);
}
}
-static void merge_stat_info(struct cache_entry **src, int nr)
+static void merge_stat_info()
{
static struct cache_entry null_entry;
- struct cache_entry **dst = src;
struct cache_entry *old = &null_entry;
+ int src = 0, dst = 0, nr = get_num_cache_entries();
- while (nr) {
+ while (src < nr) {
struct cache_entry *ce;
- ce = src[0];
+ ce = get_cache_entry(src);
/* We throw away original cache entries except for the stat
information */
if (!ce_stage(ce)) {
old = ce;
src++;
- nr--;
- active_nr--;
continue;
}
if (path_matches(ce, old) && same(ce, old))
*ce = *old;
ce->ce_flags &= ~htons(CE_STAGEMASK);
- *dst++ = ce;
+ set_cache_entry(ce, dst);
+ dst++;
src++;
+ }
+ /* this could be replaced by a truncate api */
+ while (nr > dst) {
nr--;
+ remove_cache_entry_at(nr);
}
}
@@ -233,8 +243,8 @@
if (stage)
usage("-m needs to come first");
read_cache();
- for (i = 0; i < active_nr; i++) {
- if (ce_stage(active_cache[i]))
+ for (i = 0; i < get_num_cache_entries(); i++) {
+ if (ce_stage(get_cache_entry(i)))
usage("you need to resolve your current
index first");
}
stage = 1;
@@ -252,10 +262,10 @@
if (merge) {
switch (stage) {
case 4: /* Three-way merge */
- trivially_merge_cache(active_cache, active_nr);
+ trivially_merge_cache();
break;
case 2: /* Just read a tree, merge with old cache contents */
- merge_stat_info(ac
[PATCH 08/19] rename remove_entry_at to remove_cache_entry_at and expose as a public api
tree 68af3fb1d46759f437d15f310a9aea2931708601
parent e2acfff5e544a8c6769a9e665927092b3edd7579
author Brad Roberts <[EMAIL PROTECTED]> 1114075605 -0700
committer Brad Roberts <[EMAIL PROTECTED]> 1114075605 -0700
[PATCH] rename remove_entry_at to remove_cache_entry_at and expose as a public
api
Signed-off-by: Brad Roberts <[EMAIL PROTECTED]>
---
cache.h |1 +
read-cache.c |6 +++---
2 files changed, 4 insertions(+), 3 deletions(-)
Index: cache.h
===
--- e2acfff5e544a8c6769a9e665927092b3edd7579:1/cache.h (mode:100644
sha1:9ad6e805eafcb213c6bb4b1f8ff4d4e053fa6067)
+++ 099367f98cc063c33733d15c7a2d9737bea853d9:1/cache.h (mode:100644
sha1:74d816c34245e0dde41643188f38cf99ca75e75f)
@@ -96,6 +96,7 @@
extern int get_num_cache_entries();
extern struct cache_entry * get_cache_entry(int pos);
extern void set_cache_entry(struct cache_entry *ce, int pos);
+extern int remove_cache_entry_at(int pos);
#define MTIME_CHANGED 0x0001
#define CTIME_CHANGED 0x0002
Index: read-cache.c
===
--- e2acfff5e544a8c6769a9e665927092b3edd7579:1/read-cache.c (mode:100644
sha1:8eaa05957a481b09116c37e43e16c5ef4e219a1e)
+++ 099367f98cc063c33733d15c7a2d9737bea853d9:1/read-cache.c (mode:100644
sha1:286f7136bc164f3a2317bb492138d9221efb4025)
@@ -87,7 +87,7 @@
}
/* Remove entry, return true if there are more entries to go.. */
-static int remove_entry_at(int pos)
+int remove_cache_entry_at(int pos)
{
active_nr--;
if (pos >= active_nr)
@@ -100,7 +100,7 @@
{
int pos = cache_name_pos(path, strlen(path));
if (pos >= 0)
- remove_entry_at(pos);
+ remove_cache_entry_at(pos);
return 0;
}
@@ -148,7 +148,7 @@
if (pos < active_nr && ce_stage(ce) == 0) {
while (same_name(active_cache[pos], ce)) {
ok_to_add = 1;
- if (!remove_entry_at(pos))
+ if (!remove_cache_entry_at(pos))
break;
}
}
-
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 06/19] migrate show-files.c to the new cache api's
tree a3bd48d2beba79d70e97d8647ee35a645e494350
parent f908b2542a9a3ea321633a31cf0e7ca2c8b669d4
author Brad Roberts <[EMAIL PROTECTED]> 1114074486 -0700
committer Brad Roberts <[EMAIL PROTECTED]> 1114074486 -0700
[PATCH] migrate show-files.c to the new cache api's
Signed-off-by: Brad Roberts <[EMAIL PROTECTED]>
---
show-files.c |8
1 files changed, 4 insertions(+), 4 deletions(-)
Index: show-files.c
===
--- f908b2542a9a3ea321633a31cf0e7ca2c8b669d4:1/show-files.c (mode:100644
sha1:0b49ca051de413e7182445dd8fb9144125716974)
+++ 32efd81a3292a923ce5b5ae2e39ffefd0b08664d:1/show-files.c (mode:100644
sha1:11fbbccef2df50d528105ceb48b15275f2a5693e)
@@ -116,8 +116,8 @@
printf("%s%s%c", tag_other, dir[i], line_terminator);
}
if (show_cached | show_stage) {
- for (i = 0; i < active_nr; i++) {
- struct cache_entry *ce = active_cache[i];
+ for (i = 0; i < get_num_cache_entries(); i++) {
+ struct cache_entry *ce = get_cache_entry(i);
if (show_unmerged && !ce_stage(ce))
continue;
if (!show_stage)
@@ -136,8 +136,8 @@
}
}
if (show_deleted) {
- for (i = 0; i < active_nr; i++) {
- struct cache_entry *ce = active_cache[i];
+ for (i = 0; i < get_num_cache_entries(); i++) {
+ struct cache_entry *ce = get_cache_entry(i);
struct stat st;
if (!stat(ce->name, &st))
continue;
-
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 07/19] migrate merge-cache.c over to the new cache api's
tree 8140acee0f9c57bfd87f40d1f99242c772afcdf2
parent 32efd81a3292a923ce5b5ae2e39ffefd0b08664d
author Brad Roberts <[EMAIL PROTECTED]> 1114074631 -0700
committer Brad Roberts <[EMAIL PROTECTED]> 1114074631 -0700
[PATCH] migrate merge-cache.c over to the new cache api's
Signed-off-by: Brad Roberts <[EMAIL PROTECTED]>
---
merge-cache.c | 10 +-
1 files changed, 5 insertions(+), 5 deletions(-)
Index: merge-cache.c
===
--- 32efd81a3292a923ce5b5ae2e39ffefd0b08664d:1/merge-cache.c (mode:100644
sha1:35a0d588178aa5371399458b1a15519cffd645b8)
+++ e2acfff5e544a8c6769a9e665927092b3edd7579:1/merge-cache.c (mode:100644
sha1:c2f96e7652a2aea9417c3790bfe9ab14ffcdb12f)
@@ -30,7 +30,7 @@
{
int found;
- if (pos >= active_nr)
+ if (pos >= get_num_cache_entries())
die("merge-cache: %s not in the cache", path);
arguments[0] = pgm;
arguments[1] = "";
@@ -40,7 +40,7 @@
found = 0;
do {
static char hexbuf[4][60];
- struct cache_entry *ce = active_cache[pos];
+ struct cache_entry *ce = get_cache_entry(pos);
int stage = ce_stage(ce);
if (strcmp(ce->name, path))
@@ -48,7 +48,7 @@
found++;
strcpy(hexbuf[stage], sha1_to_hex(ce->sha1));
arguments[stage] = hexbuf[stage];
- } while (++pos < active_nr);
+ } while (++pos < get_num_cache_entries());
if (!found)
die("merge-cache: %s not in the cache", path);
run_program();
@@ -70,8 +70,8 @@
static void merge_all(void)
{
int i;
- for (i = 0; i < active_nr; i++) {
- struct cache_entry *ce = active_cache[i];
+ for (i = 0; i < get_num_cache_entries(); i++) {
+ struct cache_entry *ce = get_cache_entry(i);
if (!ce_stage(ce))
continue;
i += merge_entry(i, ce->name)-1;
-
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: "GIT_INDEX_FILE" environment variable
On Thu, 21 Apr 2005, Linus Torvalds wrote: > > You can also use it to test merges without screwing up your old index file > in case something goes wrong. Btw, if it wasn't obvious, for the merge thing to work you need to first copy the old index file _or_ generate a new temporary index file first, so that doing the three-way merge has a previous index file to work with. Ie it would look something like cp .git/index .tmp-index GIT_INDEX_FILE=.tmp-index read-tree -m $orig $branch1 $branch2 but this same approach can also be used to merge things _without_ actually having any specific version checked out, in which case it would just be GIT_INDEX_FILE=.tmp-index read-tree $orig GIT_INDEX_FILE=.tmp-index read-tree -m $orig $branch1 $branch2 which allows you to create a merged index file that is totally independent on whatever (if anything) you happen to be working on right now. Together with a SHA1_FILE_DIRECTORY, it allows you to do merges entirely outside any real git tree, and without any other setup. That's quite nice for the case where your actual working tree may be dirty, and you don't want to mess around in it. Linus - To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 03/19] convert show-diff.c to use new cache hiding api's
tree bbc50100a5cfd22264c2b0731ef8678656a399d8
parent 27fc41dcd4aecafdaf583f3962697a2fa3fb6480
author Brad Roberts <[EMAIL PROTECTED]> 1114073516 -0700
committer Brad Roberts <[EMAIL PROTECTED]> 1114073516 -0700
[PATCH] convert show-diff.c to use new cache hiding api's
Signed-off-by: Brad Roberts <[EMAIL PROTECTED]>
---
show-diff.c |4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
Index: show-diff.c
===
--- 27fc41dcd4aecafdaf583f3962697a2fa3fb6480:1/show-diff.c (mode:100644
sha1:da364e26e28823f951a6be1b686a458575f28ea1)
+++ d70686e08f453199e5451b27fc7d0b36b73a5c7f:1/show-diff.c (mode:100644
sha1:e2642b65805b3e52a16c6309b44a92c2a2bd13c3)
@@ -154,7 +154,7 @@
prepare_diff_cmd();
for (i = 0; i < entries; i++) {
struct stat st;
- struct cache_entry *ce = active_cache[i];
+ struct cache_entry *ce = get_cache_entry(i);
int changed;
unsigned long size;
char type[20];
@@ -172,7 +172,7 @@
printf("%s: Unmerged\n",
ce->name);
while (i < entries &&
- !strcmp(ce->name, active_cache[i]->name))
+ !strcmp(ce->name, get_cache_entry(i)->name))
i++;
i--; /* compensate for loop control increments */
continue;
-
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 02/19] Add new api's to front the active_cache and active_nr cache internals
tree ebbf2c037e68116c4ff934f140ca12cdbe13311d
parent 77de9e0b7a81ddc22526c9415f0273171f631d3f
author Brad Roberts <[EMAIL PROTECTED]> 1114073146 -0700
committer Brad Roberts <[EMAIL PROTECTED]> 1114073146 -0700
[PATCH] Add new api's to front the active_cache and active_nr cache internals
Signed-off-by: Brad Roberts <[EMAIL PROTECTED]>
---
cache.h |3 +++
read-cache.c | 15 +++
2 files changed, 18 insertions(+)
Index: cache.h
===
--- 77de9e0b7a81ddc22526c9415f0273171f631d3f:1/cache.h (mode:100644
sha1:a101870e4a002a2548d88544a77bedad21668203)
+++ 27fc41dcd4aecafdaf583f3962697a2fa3fb6480:1/cache.h (mode:100644
sha1:9ad6e805eafcb213c6bb4b1f8ff4d4e053fa6067)
@@ -93,6 +93,9 @@
extern int add_cache_entry(struct cache_entry *ce, int ok_to_add);
extern int remove_file_from_cache(char *path);
extern int cache_match_stat(struct cache_entry *ce, struct stat *st);
+extern int get_num_cache_entries();
+extern struct cache_entry * get_cache_entry(int pos);
+extern void set_cache_entry(struct cache_entry *ce, int pos);
#define MTIME_CHANGED 0x0001
#define CTIME_CHANGED 0x0002
Index: read-cache.c
===
--- 77de9e0b7a81ddc22526c9415f0273171f631d3f:1/read-cache.c (mode:100644
sha1:349ebd1f8a0a95bf462bb1dfd3d9dfb50628829c)
+++ 27fc41dcd4aecafdaf583f3962697a2fa3fb6480:1/read-cache.c (mode:100644
sha1:6689df59d5a93e0503d7c80c114efbd16de826f3)
@@ -110,6 +110,21 @@
return ce_namelen(b) == len && !memcmp(a->name, b->name, len);
}
+int get_num_cache_entries()
+{
+ return active_nr;
+}
+
+struct cache_entry * get_cache_entry(int pos)
+{
+ return active_cache[pos];
+}
+
+void set_cache_entry(struct cache_entry *ce, int pos)
+{
+ active_cache[pos] = ce;
+}
+
int add_cache_entry(struct cache_entry *ce, int ok_to_add)
{
int pos;
-
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 04/19] Migrate update-cache.c to use the new cache api's
tree 34f7fc89e28a40387e811057065592ed2f0218a2
parent d70686e08f453199e5451b27fc7d0b36b73a5c7f
author Brad Roberts <[EMAIL PROTECTED]> 1114073784 -0700
committer Brad Roberts <[EMAIL PROTECTED]> 1114073784 -0700
[PATCH] Migrate update-cache.c to use the new cache api's
Signed-off-by: Brad Roberts <[EMAIL PROTECTED]>
---
read-cache.c |3 +++
update-cache.c | 13 +
2 files changed, 8 insertions(+), 8 deletions(-)
Index: read-cache.c
===
--- d70686e08f453199e5451b27fc7d0b36b73a5c7f:1/read-cache.c (mode:100644
sha1:6689df59d5a93e0503d7c80c114efbd16de826f3)
+++ 40bf732f5bcb986943070a2ed6c09a16543d81be:1/read-cache.c (mode:100644
sha1:8eaa05957a481b09116c37e43e16c5ef4e219a1e)
@@ -122,6 +122,9 @@
void set_cache_entry(struct cache_entry *ce, int pos)
{
+ /* You can NOT just free active_cache[i] here, since it
+* might not be necessarily malloc()ed but can also come
+* from mmap(). */
active_cache[pos] = ce;
}
Index: update-cache.c
===
--- d70686e08f453199e5451b27fc7d0b36b73a5c7f:1/update-cache.c (mode:100644
sha1:585951108c57a64bb774114d289d81fd7fd22768)
+++ 40bf732f5bcb986943070a2ed6c09a16543d81be:1/update-cache.c (mode:100644
sha1:e741f593eb9c56c596fabed7eb6b79dee2d8cba9)
@@ -204,13 +204,13 @@
{
int i;
- for (i = 0; i < active_nr; i++) {
+ for (i = 0; i < get_num_cache_entries(); i++) {
struct cache_entry *ce, *new;
- ce = active_cache[i];
+ ce = get_cache_entry(i);
if (ce_stage(ce)) {
printf("%s: needs merge\n", ce->name);
- while ((i < active_nr) &&
- ! strcmp(active_cache[i]->name, ce->name))
+ while ((i < get_num_cache_entries()) &&
+ ! strcmp(get_cache_entry(i)->name, ce->name))
i++;
i--;
continue;
@@ -221,10 +221,7 @@
printf("%s: needs update\n", ce->name);
continue;
}
- /* You can NOT just free active_cache[i] here, since it
-* might not be necessarily malloc()ed but can also come
-* from mmap(). */
- active_cache[i] = new;
+ set_cache_entry(new, i);
}
}
-
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 05/19] migrate checkout-cache.c to the new cache api's
tree b95df78e4cc90db8c4c8d0ad870bef74b7fd29e2
parent 40bf732f5bcb986943070a2ed6c09a16543d81be
author Brad Roberts <[EMAIL PROTECTED]> 1114074234 -0700
committer Brad Roberts <[EMAIL PROTECTED]> 1114074234 -0700
[PATCH] migrate checkout-cache.c to the new cache api's
Signed-off-by: Brad Roberts <[EMAIL PROTECTED]>
---
checkout-cache.c |6 +++---
1 files changed, 3 insertions(+), 3 deletions(-)
Index: checkout-cache.c
===
--- 40bf732f5bcb986943070a2ed6c09a16543d81be:1/checkout-cache.c (mode:100644
sha1:8bf86016b5d5fd88a52ce694fc59bb9ecb550d22)
+++ f908b2542a9a3ea321633a31cf0e7ca2c8b669d4:1/checkout-cache.c (mode:100644
sha1:bf9cd0572c883219d37f2788ec5f5553a136df2b)
@@ -128,15 +128,15 @@
fprintf(stderr, "checkout-cache: %s is not in the
cache\n", name);
return -1;
}
- return checkout_entry(active_cache[pos]);
+ return checkout_entry(get_cache_entry(pos));
}
static int checkout_all(void)
{
int i;
- for (i = 0; i < active_nr ; i++) {
- struct cache_entry *ce = active_cache[i];
+ for (i = 0; i < get_num_cache_entries() ; i++) {
+ struct cache_entry *ce = get_cache_entry(i);
if (ce_stage(ce))
continue;
if (checkout_entry(ce) < 0)
-
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 01/19] write_cache api signature change, isolate active_cache and active_nr inside read-cache.c
tree f45fd10b26bf98349b63427805a96bd0551cad74
parent 43fdf65356c50483233cb3d6e391b0849b2a2a50
parent cd1c034369b73da7503da365fa556aab27004814
author Brad Roberts <[EMAIL PROTECTED]> 1114072582 -0700
committer Brad Roberts <[EMAIL PROTECTED]> 1114072582 -0700
[PATCH] write_cache api signature change, isolate active_cache and active_nr
inside read-cache.c
Signed-off-by: Brad Roberts <[EMAIL PROTECTED]>
---
cache.h|2 +-
read-cache.c |8
read-tree.c|2 +-
update-cache.c |2 +-
4 files changed, 7 insertions(+), 7 deletions(-)
Index: cache.h
===
--- cd1c034369b73da7503da365fa556aab27004814:1/cache.h (mode:100644
sha1:828d660ab82bb35a1ca632a2ba4620dc483889bd)
+++ 77de9e0b7a81ddc22526c9415f0273171f631d3f:1/cache.h (mode:100644
sha1:a101870e4a002a2548d88544a77bedad21668203)
@@ -88,7 +88,7 @@
/* Initialize and use the cache information */
extern int read_cache(void);
-extern int write_cache(int newfd, struct cache_entry **cache, int entries);
+extern int write_cache(int newfd);
extern int cache_name_pos(const char *name, int namelen);
extern int add_cache_entry(struct cache_entry *ce, int ok_to_add);
extern int remove_file_from_cache(char *path);
Index: read-cache.c
===
--- cd1c034369b73da7503da365fa556aab27004814:1/read-cache.c (mode:100644
sha1:2f6a4aa18d48865db80459a3459ac4384b0b16c8)
+++ 77de9e0b7a81ddc22526c9415f0273171f631d3f:1/read-cache.c (mode:100644
sha1:349ebd1f8a0a95bf462bb1dfd3d9dfb50628829c)
@@ -267,7 +267,7 @@
return 0;
}
-int write_cache(int newfd, struct cache_entry **cache, int entries)
+int write_cache(int newfd)
{
SHA_CTX c;
struct cache_header hdr;
@@ -275,14 +275,14 @@
hdr.hdr_signature = htonl(CACHE_SIGNATURE);
hdr.hdr_version = htonl(2);
- hdr.hdr_entries = htonl(entries);
+ hdr.hdr_entries = htonl(active_nr);
SHA1_Init(&c);
if (ce_write(&c, newfd, &hdr, sizeof(hdr)) < 0)
return -1;
- for (i = 0; i < entries; i++) {
- struct cache_entry *ce = cache[i];
+ for (i = 0; i < active_nr; i++) {
+ struct cache_entry *ce = active_cache[i];
if (ce_write(&c, newfd, ce, ce_size(ce)) < 0)
return -1;
}
Index: read-tree.c
===
--- cd1c034369b73da7503da365fa556aab27004814:1/read-tree.c (mode:100644
sha1:620f3f74eb56366fca8be4d28d7b04875c0fa90c)
+++ 77de9e0b7a81ddc22526c9415f0273171f631d3f:1/read-tree.c (mode:100644
sha1:4ad48f5c409ead69407d2b5feab4466cdcb499f8)
@@ -261,7 +261,7 @@
die("just how do you expect me to merge %d trees?",
stage-1);
}
}
- if (write_cache(newfd, active_cache, active_nr) ||
+ if (write_cache(newfd) ||
rename(".git/index.lock", ".git/index"))
die("unable to write new index file");
remove_lock = 0;
Index: update-cache.c
===
--- cd1c034369b73da7503da365fa556aab27004814:1/update-cache.c (mode:100644
sha1:a09883541c745c76413c62109a80f40df4b7a7fb)
+++ 77de9e0b7a81ddc22526c9415f0273171f631d3f:1/update-cache.c (mode:100644
sha1:585951108c57a64bb774114d289d81fd7fd22768)
@@ -341,7 +341,7 @@
if (add_file_to_cache(path))
die("Unable to add %s to database", path);
}
- if (write_cache(newfd, active_cache, active_nr) ||
+ if (write_cache(newfd) ||
rename(".git/index.lock", ".git/index"))
die("Unable to write new cachefile");
-
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 00/19] summary of patch set
Tonight I did a bunch of tiny steps towards making the cache management code behave more like a library. There are no longer any global variables in read-cache.c. Nothing ever uses more than one cache yet, but I can see how it might simplify some of the merge code. They're also visible here: http://gameboy2.puremagic.com:8090/ [PATCH 01/19] write_cache api signature change, isolate active_cache and active_nr inside read-cache.c [PATCH 02/19] Add new api's to front the active_cache and active_nr cache internals [PATCH 03/19] convert show-diff.c to use new cache hiding api's [PATCH 04/19] Migrate update-cache.c to use the new cache api's [PATCH 05/19] migrate checkout-cache.c to the new cache api's [PATCH 06/19] migrate show-files.c to the new cache api's [PATCH 07/19] migrate merge-cache.c over to the new cache api's [PATCH 08/19] rename remove_entry_at to remove_cache_entry_at and expose as a public api [PATCH 09/19] migrate read-tree.c to the new cache api's [PATCH 10/19] migrate check-files.c to the new cache api's [PATCH 11/19] migrate write-tree.c to use the new cache api's [PATCH 12/19] fix up diff-cache.c to use new cache api's [PATCH 13/19] Remove active_cache, active_nr, and active_alloc from public view [PATCH 14/19] move cache_header out of the public view [PATCH 15/19] introduce a cache struct and move the various cache globals into it. [PATCH 16/19] change all call sites that use the return value of read_cache to get the # of cache entries. [PATCH 17/19] temporarily change add_cache_entry to create an empty cache on demand [PATCH 18/19] rename cache_match_stat to ce_match_stat to match other cache_entry related functions/macros [PATCH 19/19] the end goal of the last dozen or so commits, there's no longer a global cache variable [PATCH 01-19/19] All of the above combined - To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Removing command dispatcher (was Re: [ANNOUNCE] git-pasky-0.6.2 && heads-up on upcoming changes)
Matthias Urlichs wrote: Linus Torvalds wrote: I realize that there is probably a law that there has to be a space, but I actually personally use tab-completion all the time It's very unusual, but I can't think of any crisis it causes. One minor annoyance: Windows doesn't support #! magic headers, and a very few-and-probably-ignorable old Unix systems don't either. There, commands written in an interpreter like perl, python, or shell can't be kicked off just by a #! reference at the top (standard Windows' shell is incompatible anyway, so it's just as well in the case of shell). I don't see this as a roadblock, though. On those systems, you could create trivial stubs that just invoke the interpreter (e.g., perl) and the real program. In the Windows case, you can use Windows' miserable excuse for a command processor to do that very easily. E.g., if "cg-update" is a Perl script, then you can create a file "cg-update.bat": perl \path\to\cg-update %* (That requires Windows NT4 or better. MS-DOS didn't have %*, so you needed: perl \path\to\cg-update %1 %2 %3 %4 %5 %6 %7 %8 %9 It's hard to imagine an MS-DOS git user though.) --- David A. Wheeler - To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: "GIT_INDEX_FILE" environment variable
On Thu, 21 Apr 2005, Linus Torvalds wrote: > Did I already happen to mention that I think that the git model is the > best model ever, and that I'm just not an incredibly good-looking hunk and > becomingly modest, I'm smart too? You forgot, *again*, to take your medications !! - Davide - To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
"GIT_INDEX_FILE" environment variable
This checkin goes along with the previous one, and makes it easier to use all the normal git operations on temporary index files: Add support for a "GIT_INDEX_FILE" environment variable. We use that to specify alternative index files, which can be useful if you want to (for example) generate a temporary index file to do some specific operation that you don't want to mess with your main one with. It defaults to the regular ".git/index" if it hasn't been specified. and it's particularly useful for doing things like "read a tree into a temporary index file, and write the result out". For example, say that you wanted to know what the Makefile looked like in a particular release, you could do GIT_INDEX_FILE=.tmp-index read-tree $release GIT_INDEX_FILE=.tmp-index checkout-cache --prefix=old- Makefile rm .tmp-index and you're done. Your old Makefile version is now in "old-Makefile" (and this is also where it's nice that checkout-cache refuses to overwrite existing files by default: if you forgot or messed up the prefix, it's all good). You can also use it to test merges without screwing up your old index file in case something goes wrong. Did I already happen to mention that I think that the git model is the best model ever, and that I'm just not an incredibly good-looking hunk and becomingly modest, I'm smart too? Linus - To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
"checkout-cache" update
I just pushed out this very useful thing to "checkout-cache", which is best just described by its commit log: Add the ability to prefix something to the pathname to "checkout-cache.c" This basically makes it trivial to use checkout-cache as a "export as tree" function. Just read the desired tree into the index, and do a checkout-cache --prefix=export-dir/ -a and checkout-cache will "export" the cache into the specified directory. NOTE! The final "/" is important. The exported name is literally just prefixed with the specified string, so you can also do something like checkout-cache --prefix=.merged- Makefile to check out the currently cached copy of "Makefile" into the file ".merged-Makefile". Basically, I can do a a "git-0.6" release with a simple checkout-cache --prefix=../git-0.6/ -a which basically says: check out all files, but use the prefix "../git-0.6/" before the filename when you do so. Then I just do cd .. tar czvf git-0.6.tar.gz git-0.6 and I'm done. Very cool, very simple, and _extremely_ fast. Doing the tree export (not the tar) for the whole kernel takes two minutes in the cold-cache case (not so wonderful, but acceptable), and 4.6 _seconds_ in the hot-cache case (pretty damn impressive, I say). (The compressng tar then takes about 20 seconds for me, and that's obviously all from the cache, since I just wrote it out). NOTE! The fact that the '/' at the end of the --prefix= thing is meaningful can be very confusing, I freely admit. But it does end up being potentially quite useful, and you're likely to script usage of this anyway into "git export" or something, so... Linus - To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: zlib version, list archives
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? | | I apologize in advance if this has already been asked, I cannot find an | archive of this list. Could somebody point me to one? http://marc.theaimsgroup.com/?l=git or http://dir.gmane.org/gmane.comp.version-control.git --- ~Randy - To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
zlib version, list archives
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? I apologize in advance if this has already been asked, I cannot find an archive of this list. Could somebody point me to one? - To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: on when to checksum
Tom Lord graced us with: > I think you have made a mistake by moving the sha1 checksum from the > zipped form to the inflated form. Here is why: > > What you have set in motion with `git' is an ad-hoc p2p network for > sharing filesystem trees -- a global distributed filesystem. I > believe your starter here has a good chance of taking off to be much, > much larger than just a tool for the kernel. This might rather be a call for a git derivative. As Linus has already mentioned in this thread, git is optimized for his need for local speed. But while sacrificing local speed for network speed would break git by stepping away from the git philosophy, a gitling with a different philosophy but making use of gitish techniques could make that change without being broken even though git itself can't. - To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: git-viz tool for visualising commit trees
Dear diary, on Thu, Apr 21, 2005 at 04:47:16PM CEST, I got a letter where Ingo Molnar <[EMAIL PROTECTED]> told me that... > > is the 'diff with ancestor' feature supposed to work at this early > stage? (it just does nothing when i click on it. It correctly offers two > ancestors for merge points, but does nothing there either.) Doesn't it require git diff? -- Petr "Pasky" Baudis Stuff: http://pasky.or.cz/ C++: an octopus made by nailing extra legs onto a dog. -- Steve Taylor - To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] Improve usage messages
Petr Baudis wrote: Dear diary, on Thu, Apr 21, 2005 at 02:41:52PM CEST, I got a letter where Matthias Urlichs <[EMAIL PROTECTED]> told me that... This patch adds somewhat-improved usage messages to some of Linus' programs. Specifically, they now handle -? / --help. just so you know, the intention of doing the README.reference was to get all the docs in one place and then go back to the c and update the usage() to be consistent. I started by doing grep usage *.c :) I'm actually working on diff-cache as we speak... David - To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [ANNOUNCE] git-pasky-0.6.2 && heads-up on upcoming changes
Dear diary, on Thu, Apr 21, 2005 at 04:21:00PM CEST, I got a letter where Edgar Toernig <[EMAIL PROTECTED]> told me that... > Petr Baudis wrote: > > > > A little off-topic, anyone knows how to turn off that damn alternate > > screen thing on the xterm level? (Or any other level which makes _all_ > > programs not to use it.) > > Change the terminfo entry. That's why I asked for how to do it on the xterm level. Some programs don't care about term(cap|info). And I may not be root. -- Petr "Pasky" Baudis Stuff: http://pasky.or.cz/ C++: an octopus made by nailing extra legs onto a dog. -- Steve Taylor - To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Switching between branches
Dear diary, on Thu, Apr 21, 2005 at 04:12:49PM CEST, I got a letter where Matthias Urlichs <[EMAIL PROTECTED]> told me that... > Hi, Petr Baudis wrote: > > > Hello, > > > >> Perhaps it's a naive question, but how do I switch between branches? I > >> mean an equivalent of "svn switch" or "cvs update -r branch" that would > >> reuse the existing working directory. > > > > you can't. There was 'git update' (and intermediate never-committed 'git > > switch'), but I decided not to support it for now, since I don't have any > > compelling usage case for it. > > I do -- I have a project which builds several slightly-customized versions, > and I'd like to keep the generated objects around if possible. > > So I just build one version, then "git cancel FOO" to the next version, > and let the make rules take care of rebuilding what needs to be rebuilt. I suppose we could do with git switch then. -- Petr "Pasky" Baudis Stuff: http://pasky.or.cz/ C++: an octopus made by nailing extra legs onto a dog. -- Steve Taylor - To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] Improve usage messages
Dear diary, on Thu, Apr 21, 2005 at 02:41:52PM CEST, I got a letter
where Matthias Urlichs <[EMAIL PROTECTED]> told me that...
> This patch adds somewhat-improved usage messages to some of Linus' programs.
> Specifically, they now handle -? / --help.
-? is pretty non-standard. Any problem with going for -h?
> Signed-Off-By: Matthias Urlichs <[EMAIL PROTECTED]>
>
> Index: check-files.c
> ===
> --- 42a073eb6b5bb397a3e8768a032463a7fa02e6b9/check-files.c (mode:100644
> sha1:7d16691aa9d51b5b4670d5837b3527ee7c7da79c)
> +++ 265515f9c4f089b1b61e9d2312c4b3babe189618/check-files.c (mode:100644
> sha1:be904b13659a60eab31787b010a64f2274048a9f)
> @@ -40,6 +40,8 @@
> {
> int i;
>
> + if(argc == 2 && (!strcmp(argv[1],"-?") || !strcmp(argv[1],"--help")))
(style-education-hat
+ if (argc == 2 && (!strcmp(argv[1], "-?") || !strcmp(argv[1], "--help")))
)
> + usage("check-files filename...");
Let's either do * or FILE..., this mixing doesn't look good.
> read_cache();
> for (i = 1; i < argc ; i++)
> check_file(argv[i]);
> Index: diff-tree.c
> ===
> --- 42a073eb6b5bb397a3e8768a032463a7fa02e6b9/diff-tree.c (mode:100644
> sha1:b0122e42631410fa579115f025efc3cab777cde6)
> +++ 265515f9c4f089b1b61e9d2312c4b3babe189618/diff-tree.c (mode:100644
> sha1:03fcc2fae2f0b06f3834f0b6e0d8762e70f49f51)
> @@ -193,6 +193,11 @@
> }
> }
>
> +static const char diff_tree_usage[] =
> + "diff-tree [ -r (recurse) | -z (\\0-terminate) ]"
> + "\n\t ";
I'd say this is pretty confusnig. Just describe the parameters on
folowing lines in more detail, if you must.
> +
> +
> int main(int argc, char **argv)
> {
> unsigned char old[20], new[20];
--
Petr "Pasky" Baudis
Stuff: http://pasky.or.cz/
C++: an octopus made by nailing extra legs onto a dog. -- Steve Taylor
-
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
