* Re: Tutorial problem a/a a/b
From: Darrin Thompson @ 2005-07-29 14:07 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vy87qkwdp.fsf@assigned-by-dhcp.cox.net>
On Thu, 2005-07-28 at 22:35 -0700, Junio C Hamano wrote:
> Darrin Thompson <darrint@progeny.com> writes:
>
> > In the tutorial the user is instructed to create two files: a and b.
> >
> > Then when the user diffs the files, they see this:
> >
> > diff --git a/a b/a
> >
> > That really confused somebody and I had to untangle their brain. :-)
>
> Yes I was confused when I read it for the first time.
> How does this look?
Looks good to me and guy with the original question.
--
Darrin
^ permalink raw reply
* Re: Dump http servers still slow?
From: Ryan Anderson @ 2005-07-29 14:48 UTC (permalink / raw)
To: Darrin Thompson; +Cc: Junio C Hamano, git
In-Reply-To: <1122645821.4263.6.camel@localhost.localdomain>
On Fri, Jul 29, 2005 at 09:03:41AM -0500, Darrin Thompson wrote:
>
> Where is the code for gitweb? (i.e. http://kernel.org/git ) Seems like
> it could benefit from some git-send-pack superpowers.
http://www.kernel.org/pub/software/scm/gitweb/
It occurs to me that pulling this into the main git repository might not
be a bad idea, since it is currently living outside any revision
tracking at the moment.
--
Ryan Anderson
sometimes Pug Majere
^ permalink raw reply
* Re: [PATCH] mmap error handling
From: Pavel Roskin @ 2005-07-29 14:49 UTC (permalink / raw)
To: git
In-Reply-To: <Pine.LNX.4.58.0507281725440.3307@g5.osdl.org>
Hi, Linus!
On Thu, 2005-07-28 at 17:30 -0700, Linus Torvalds wrote:
> _always_ save the value of errno before doing any other calls. Even
> successful calls are perfectly allowed to change errno.
OK. Fixed patch below.
Signed-off-by: Pavel Roskin <proski@gnu.org>
diff --git a/diff.c b/diff.c
--- a/diff.c
+++ b/diff.c
@@ -377,8 +377,10 @@ int diff_populate_filespec(struct diff_f
if (fd < 0)
goto err_empty;
s->data = mmap(NULL, s->size, PROT_READ, MAP_PRIVATE, fd, 0);
- s->should_munmap = 1;
close(fd);
+ if (s->data == MAP_FAILED)
+ goto err_empty;
+ s->should_munmap = 1;
}
else {
char type[20];
diff --git a/diffcore-order.c b/diffcore-order.c
--- a/diffcore-order.c
+++ b/diffcore-order.c
@@ -28,7 +28,7 @@ static void prepare_order(const char *or
}
map = mmap(NULL, st.st_size, PROT_READ|PROT_WRITE, MAP_PRIVATE, fd, 0);
close(fd);
- if (-1 == (int)(long)map)
+ if (map == MAP_FAILED)
return;
endp = map + st.st_size;
for (pass = 0; pass < 2; pass++) {
diff --git a/local-pull.c b/local-pull.c
--- a/local-pull.c
+++ b/local-pull.c
@@ -54,7 +54,7 @@ int fetch(unsigned char *sha1)
}
map = mmap(NULL, st.st_size, PROT_READ, MAP_PRIVATE, ifd, 0);
close(ifd);
- if (-1 == (int)(long)map) {
+ if (map == MAP_FAILED) {
fprintf(stderr, "cannot mmap %s\n", filename);
return -1;
}
diff --git a/read-cache.c b/read-cache.c
--- a/read-cache.c
+++ b/read-cache.c
@@ -392,7 +392,7 @@ int read_cache(void)
return (errno == ENOENT) ? 0 : error("open failed");
size = 0; // avoid gcc warning
- map = (void *)-1;
+ map = MAP_FAILED;
if (!fstat(fd, &st)) {
size = st.st_size;
errno = EINVAL;
@@ -400,7 +400,7 @@ int read_cache(void)
map = mmap(NULL, size, PROT_READ | PROT_WRITE, MAP_PRIVATE, fd, 0);
}
close(fd);
- if (-1 == (int)(long)map)
+ if (map == MAP_FAILED)
return error("mmap failed");
hdr = map;
diff --git a/rev-cache.c b/rev-cache.c
--- a/rev-cache.c
+++ b/rev-cache.c
@@ -212,11 +212,9 @@ int read_rev_cache(const char *path, FIL
return -1;
}
map = mmap(NULL, st.st_size, PROT_READ, MAP_PRIVATE, fd, 0);
- if (map == MAP_FAILED) {
- close(fd);
- return -1;
- }
close(fd);
+ if (map == MAP_FAILED)
+ return -1;
memset(last_sha1, 0, 20);
ofs = 0;
diff --git a/sha1_file.c b/sha1_file.c
--- a/sha1_file.c
+++ b/sha1_file.c
@@ -518,7 +518,7 @@ static void *map_sha1_file_internal(cons
}
map = mmap(NULL, st.st_size, PROT_READ, MAP_PRIVATE, fd, 0);
close(fd);
- if (-1 == (int)(long)map)
+ if (map == MAP_FAILED)
return NULL;
*size = st.st_size;
return map;
@@ -1363,7 +1363,7 @@ int index_fd(unsigned char *sha1, int fd
if (size)
buf = mmap(NULL, size, PROT_READ, MAP_PRIVATE, fd, 0);
close(fd);
- if ((int)(long)buf == -1)
+ if (buf == MAP_FAILED)
return -1;
if (!type)
diff --git a/test-delta.c b/test-delta.c
--- a/test-delta.c
+++ b/test-delta.c
@@ -41,6 +41,7 @@ int main(int argc, char *argv[])
from_buf = mmap(NULL, from_size, PROT_READ, MAP_PRIVATE, fd, 0);
if (from_buf == MAP_FAILED) {
perror(argv[2]);
+ close(fd);
return 1;
}
close(fd);
@@ -54,6 +55,7 @@ int main(int argc, char *argv[])
data_buf = mmap(NULL, data_size, PROT_READ, MAP_PRIVATE, fd, 0);
if (data_buf == MAP_FAILED) {
perror(argv[3]);
+ close(fd);
return 1;
}
close(fd);
diff --git a/tools/mailsplit.c b/tools/mailsplit.c
--- a/tools/mailsplit.c
+++ b/tools/mailsplit.c
@@ -116,8 +116,9 @@ int main(int argc, char **argv)
}
size = st.st_size;
map = mmap(NULL, size, PROT_READ, MAP_PRIVATE, fd, 0);
- if (-1 == (int)(long)map) {
+ if (map == MAP_FAILED) {
perror("mmap");
+ close(fd);
exit(1);
}
close(fd);
--
Regards,
Pavel Roskin
^ permalink raw reply
* Re: Dump http servers still slow?
From: Darrin Thompson @ 2005-07-29 14:57 UTC (permalink / raw)
To: Ryan Anderson; +Cc: Junio C Hamano, git
In-Reply-To: <20050729144802.GA2280@mythryan2.michonline.com>
On Fri, 2005-07-29 at 10:48 -0400, Ryan Anderson wrote:
> On Fri, Jul 29, 2005 at 09:03:41AM -0500, Darrin Thompson wrote:
> >
> > Where is the code for gitweb? (i.e. http://kernel.org/git ) Seems like
> > it could benefit from some git-send-pack superpowers.
>
> http://www.kernel.org/pub/software/scm/gitweb/
>
> It occurs to me that pulling this into the main git repository might not
> be a bad idea, since it is currently living outside any revision
> tracking at the moment.
>
Can't see the code.
http://www.kernel.org/pub/software/scm/gitweb/gitweb.cgi
Internal Server Error
--
Darrin
^ permalink raw reply
* Re: Dump http servers still slow?
From: Radoslaw AstralStorm Szkodzinski @ 2005-07-29 15:08 UTC (permalink / raw)
To: Darrin Thompson; +Cc: ryan, junkio, git
In-Reply-To: <1122649056.4263.13.camel@localhost.localdomain>
[-- Attachment #1: Type: text/plain, Size: 365 bytes --]
On Fri, 29 Jul 2005 09:57:36 -0500
Darrin Thompson <darrint@progeny.com> wrote:
> Can't see the code.
>
> http://www.kernel.org/pub/software/scm/gitweb/gitweb.cgi
>
> Internal Server Error
>
Use FTP.
--
AstralStorm
GPG Key ID = 0xD1F10BA2
GPG Key fingerprint = 96E2 304A B9C4 949A 10A0 9105 9543 0453 D1F1 0BA2
Please encrypt if you can.
[-- Attachment #2: Type: application/pgp-signature, Size: 198 bytes --]
^ permalink raw reply
* Re: Dump http servers still slow?
From: Darrin Thompson @ 2005-07-29 15:26 UTC (permalink / raw)
To: Radoslaw AstralStorm Szkodzinski; +Cc: ryan, junkio, git
In-Reply-To: <20050729170824.5a946769.astralstorm@gorzow.mm.pl>
On Fri, 2005-07-29 at 17:08 +0200, Radoslaw AstralStorm Szkodzinski
wrote:
> On Fri, 29 Jul 2005 09:57:36 -0500
> Darrin Thompson <darrint@progeny.com> wrote:
>
> > Can't see the code.
> >
> > http://www.kernel.org/pub/software/scm/gitweb/gitweb.cgi
> >
> > Internal Server Error
> >
>
> Use FTP.
>
Duh. Thanks.
--
Darrin
^ permalink raw reply
* [PATCH 5/2] Remove the explicit Makefile dependencies description
From: Petr Baudis @ 2005-07-29 15:48 UTC (permalink / raw)
To: junkio; +Cc: git
In-Reply-To: <20050729085819.GL24895@pasky.ji.cz>
Remove about one gazillion of explicit dependency rules with few lines
describing the general dependency pattern and then the exceptions. This
noticably shortens the Makefile and makes it easier to touch it.
This is part of the Cogito Makefile changes port.
Signed-off-by: Petr Baudis <pasky@ucw.cz>
---
commit ee84cc0f730f0e744fe8d922b24f6f7ebe31d737
tree 0b3edc11a0eba131788e42768b56ba6ceba32b96
parent 601722751e42dfef8bcd2fe3d6b070b07eb9198e
author Petr Baudis <pasky@suse.cz> Fri, 29 Jul 2005 15:46:40 +0200
committer Petr Baudis <xpasky@machine.sinus.cz> Fri, 29 Jul 2005 15:46:40 +0200
Makefile | 74 +++++++-------------------------------------------------------
1 files changed, 8 insertions(+), 66 deletions(-)
diff --git a/Makefile b/Makefile
--- a/Makefile
+++ b/Makefile
@@ -97,8 +97,9 @@ LIB_H += quote.h
LIB_OBJS += quote.o
LIB_H += diff.h count-delta.h
-LIB_OBJS += diff.o diffcore-rename.o diffcore-pickaxe.o diffcore-pathspec.o \
- count-delta.o diffcore-break.o diffcore-order.o
+DIFF_OBJS = diff.o diffcore-rename.o diffcore-pickaxe.o diffcore-pathspec.o \
+ diffcore-break.o diffcore-order.o
+LIB_OBJS += $(DIFF_OBJS) count-delta.o
LIB_OBJS += gitenv.o
LIB_OBJS += server-info.o
@@ -136,75 +137,16 @@ test-delta: test-delta.c diff-delta.o pa
git-%: %.c $(LIB_FILE)
$(CC) $(CFLAGS) -o $@ $(filter %.c,$^) $(LIBS)
-git-update-cache: update-cache.c
-git-diff-files: diff-files.c
-git-init-db: init-db.c
-git-write-tree: write-tree.c
-git-read-tree: read-tree.c
-git-commit-tree: commit-tree.c
-git-cat-file: cat-file.c
-git-fsck-cache: fsck-cache.c
-git-checkout-cache: checkout-cache.c
-git-diff-tree: diff-tree.c
-git-rev-tree: rev-tree.c
-git-ls-files: ls-files.c
-git-check-files: check-files.c
-git-ls-tree: ls-tree.c
-git-merge-base: merge-base.c
-git-merge-cache: merge-cache.c
-git-unpack-file: unpack-file.c
-git-export: export.c
-git-diff-cache: diff-cache.c
-git-convert-cache: convert-cache.c
-git-http-pull: http-pull.c pull.c
-git-local-pull: local-pull.c pull.c
-git-ssh-push: rsh.c
+git-http-pull: pull.c
+git-local-pull: pull.c
git-ssh-pull: rsh.c pull.c
-git-rev-list: rev-list.c
-git-mktag: mktag.c
-git-diff-helper: diff-helper.c
-git-tar-tree: tar-tree.c
-git-hash-object: hash-object.c
-git-stripspace: stripspace.c
-git-diff-stages: diff-stages.c
-git-rev-parse: rev-parse.c
-git-patch-id: patch-id.c
-git-pack-objects: pack-objects.c
-git-unpack-objects: unpack-objects.c
-git-verify-pack: verify-pack.c
-git-receive-pack: receive-pack.c
-git-send-pack: send-pack.c
-git-prune-packed: prune-packed.c
-git-fetch-pack: fetch-pack.c
-git-var: var.c
-git-peek-remote: peek-remote.c
-git-update-server-info: update-server-info.c
-git-build-rev-cache: build-rev-cache.c
-git-show-rev-cache: show-rev-cache.c
+git-ssh-push: rsh.c
git-http-pull: LIBS += -lcurl
git-rev-list: LIBS += -lssl
-# Library objects..
-blob.o: $(LIB_H)
-tree.o: $(LIB_H)
-commit.o: $(LIB_H)
-tag.o: $(LIB_H)
-object.o: $(LIB_H)
-read-cache.o: $(LIB_H)
-sha1_file.o: $(LIB_H)
-usage.o: $(LIB_H)
-rev-cache.o: $(LIB_H)
-strbuf.o: $(LIB_H)
-gitenv.o: $(LIB_H)
-entry.o: $(LIB_H)
-diff.o: $(LIB_H) diffcore.h
-diffcore-rename.o : $(LIB_H) diffcore.h
-diffcore-pathspec.o : $(LIB_H) diffcore.h
-diffcore-pickaxe.o : $(LIB_H) diffcore.h
-diffcore-break.o : $(LIB_H) diffcore.h
-diffcore-order.o : $(LIB_H) diffcore.h
-epoch.o: $(LIB_H)
+$(LIB_OBJS): $(LIB_H)
+$(DIFF_OBJS): diffcore.h
git-core.spec: git-core.spec.in Makefile
sed -e 's/@@VERSION@@/$(GIT_VERSION)/g' < $< > $@
^ permalink raw reply
* [PATCH 4/2] Improve the compilation-time settings interface
From: Petr Baudis @ 2005-07-29 15:48 UTC (permalink / raw)
To: junkio; +Cc: git
In-Reply-To: <20050729085819.GL24895@pasky.ji.cz>
Describe variables which make itself takes and adjusts compilation
accordingly (MOZILLA_SHA1, NO_OPENSSL, PPC_SHA1), and make adding
defines more convenient through the $DEFINES variable. $COPTS includes
-g as well now and is not overriden if it was already declared in the
environment. Also, $CFLAGS is appended to rather than reset, so that if
there was already a $CFLAGS environment variable, it's appended to. Some
more variables are also made overridable through the environment. Renamed
$bin to $bindir which is the name commonly used for this.
This is part of the Cogito Makefile changes port.
Signed-off-by: Petr Baudis <pasky@ucw.cz>
---
commit 601722751e42dfef8bcd2fe3d6b070b07eb9198e
tree ebe576c5bd841b4daeb855e49635491c02a322b5
parent 8ddefe85adc8e035864be615c87844ef982f4bc6
author Petr Baudis <pasky@suse.cz> Fri, 29 Jul 2005 15:45:42 +0200
committer Petr Baudis <xpasky@machine.sinus.cz> Fri, 29 Jul 2005 15:45:42 +0200
Makefile | 56 ++++++++++++++++++++++++++++++++++++++------------------
1 files changed, 38 insertions(+), 18 deletions(-)
diff --git a/Makefile b/Makefile
--- a/Makefile
+++ b/Makefile
@@ -1,33 +1,53 @@
-# -DCOLLISION_CHECK if you believe that SHA1's
-# 1461501637330902918203684832716283019655932542976 hashes do not give you
-# enough guarantees about no collisions between objects ever hapenning.
+# Define MOZILLA_SHA1 environment variable when running make to make use of
+# a bundled SHA1 routine coming from Mozilla. It is GPL'd and should be fast
+# on non-x86 architectures (e.g. PowerPC), while the OpenSSL version (default
+# choice) has very fast version optimized for i586.
#
-# -DUSE_NSEC if you want git to care about sub-second file mtimes and ctimes.
-# -DUSE_STDEV if you want git to care about st_dev changing
+# Define NO_OPENSSL environment variable if you do not have OpenSSL. You will
+# miss out git-rev-list --merge-order. This also implies MOZILLA_SHA1.
#
-# Note that you need some new glibc (at least >2.2.4) for this, and it will
-# BREAK YOUR LOCAL DIFFS! show-diff and anything using it will likely randomly
-# break unless your underlying filesystem supports those sub-second times
-# (my ext3 doesn't).
+# Define PPC_SHA1 environment variable when running make to make use of
+# a bundled SHA1 routine optimized for PowerPC.
+
+
+# Define COLLISION_CHECK below if you believe that SHA1's
+# 1461501637330902918203684832716283019655932542976 hashes do not give you
+# sufficient guarantee that no collisions between objects will ever happen.
+
+# DEFINES += -DCOLLISION_CHECK
+
+# Define USE_NSEC below if you want git to care about sub-second file mtimes
+# and ctimes. Note that you need recent glibc (at least 2.2.4) for this, and
+# it will BREAK YOUR LOCAL DIFFS! show-diff and anything using it will likely
+# randomly break unless your underlying filesystem supports those sub-second
+# times (my ext3 doesn't).
+
+# DEFINES += -DUSE_NSEC
+
+# Define USE_STDEV below if you want git to care about the underlying device
+# change being considered an inode change from the update-cache perspective.
+
+# DEFINES += -DUSE_STDEV
+
GIT_VERSION=0.99.2
-COPTS=-O2
-CFLAGS=-g $(COPTS) -Wall
+COPTS?=-g -O2
+CFLAGS+=$(COPTS) -Wall $(DEFINES)
prefix=$(HOME)
-bin=$(prefix)/bin
+bindir=$(prefix)/bin
# dest=
-CC=gcc
-AR=ar
-INSTALL=install
-RPMBUILD=rpmbuild
+CC?=gcc
+AR?=ar
+INSTALL?=install
+RPMBUILD?=rpmbuild
#
# sparse is architecture-neutral, which means that we need to tell it
# explicitly what architecture to check for. Fix this up for yours..
#
-SPARSE_FLAGS=-D__BIG_ENDIAN__ -D__powerpc__
+SPARSE_FLAGS?=-D__BIG_ENDIAN__ -D__powerpc__
SCRIPTS=git git-apply-patch-script git-merge-one-file-script git-prune-script \
git-pull-script git-tag-script git-resolve-script git-whatchanged \
@@ -57,7 +77,7 @@ PROG= git-update-cache git-diff-files
all: $(PROG)
install: $(PROG) $(SCRIPTS)
- $(INSTALL) -m755 -d $(dest)$(bin)
+ $(INSTALL) -m755 -d $(dest)$(bindir)
$(INSTALL) $(PROG) $(SCRIPTS) $(dest)$(bin)
LIB_OBJS=read-cache.o sha1_file.o usage.o object.o commit.o tree.o blob.o \
^ permalink raw reply
* [PATCH 6/2] Reorder Makefile rules
From: Petr Baudis @ 2005-07-29 15:50 UTC (permalink / raw)
To: junkio; +Cc: git
In-Reply-To: <20050729085819.GL24895@pasky.ji.cz>
The Makefile rules were massively reordered so that they are actually
logically grouped now. Captions were added to separate the sections. No
rule contents was touched during the process.
Signed-off-by: Petr Baudis <pasky@ucw.cz>
---
commit 656a66fe63898954dbc40854dd049dc76eb9b841
tree a5b29a2163c1bbd671a1dc40d0cb6dade3c4aaee
parent ee84cc0f730f0e744fe8d922b24f6f7ebe31d737
author Petr Baudis <pasky@suse.cz> Fri, 29 Jul 2005 17:02:14 +0200
committer Petr Baudis <xpasky@machine.sinus.cz> Fri, 29 Jul 2005 17:02:14 +0200
Makefile | 87 +++++++++++++++++++++++++++++++++++++++++---------------------
1 files changed, 57 insertions(+), 30 deletions(-)
diff --git a/Makefile b/Makefile
--- a/Makefile
+++ b/Makefile
@@ -43,12 +43,16 @@ AR?=ar
INSTALL?=install
RPMBUILD?=rpmbuild
-#
# sparse is architecture-neutral, which means that we need to tell it
# explicitly what architecture to check for. Fix this up for yours..
-#
SPARSE_FLAGS?=-D__BIG_ENDIAN__ -D__powerpc__
+
+
+### --- END CONFIGURATION SECTION ---
+
+
+
SCRIPTS=git git-apply-patch-script git-merge-one-file-script git-prune-script \
git-pull-script git-tag-script git-resolve-script git-whatchanged \
git-fetch-script git-status-script git-commit-script \
@@ -74,18 +78,12 @@ PROG= git-update-cache git-diff-files
git-show-index git-daemon git-var git-peek-remote \
git-update-server-info git-show-rev-cache git-build-rev-cache
-all: $(PROG)
-
-install: $(PROG) $(SCRIPTS)
- $(INSTALL) -m755 -d $(dest)$(bindir)
- $(INSTALL) $(PROG) $(SCRIPTS) $(dest)$(bin)
-
-LIB_OBJS=read-cache.o sha1_file.o usage.o object.o commit.o tree.o blob.o \
- tag.o date.o index.o diff-delta.o patch-delta.o entry.o path.o \
- epoch.o refs.o csum-file.o pack-check.o pkt-line.o connect.o ident.o
LIB_FILE=libgit.a
LIB_H=cache.h object.h blob.h tree.h commit.h tag.h delta.h epoch.h csum-file.h \
pack.h pkt-line.h refs.h
+LIB_OBJS=read-cache.o sha1_file.o usage.o object.o commit.o tree.o blob.o \
+ tag.o date.o index.o diff-delta.o patch-delta.o entry.o path.o \
+ epoch.o refs.o csum-file.o pack-check.o pkt-line.o connect.o ident.o
LIB_H += rev-cache.h
LIB_OBJS += rev-cache.o
@@ -122,17 +120,12 @@ endif
CFLAGS += '-DSHA1_HEADER=$(SHA1_HEADER)'
-$(LIB_FILE): $(LIB_OBJS)
- $(AR) rcs $@ $(LIB_OBJS)
-check:
- for i in *.c; do sparse $(CFLAGS) $(SPARSE_FLAGS) $$i; done
-test-date: test-date.c date.o
- $(CC) $(CFLAGS) -o $@ test-date.c date.o
+### Build rules
+
+all: $(PROG)
-test-delta: test-delta.c diff-delta.o patch-delta.o
- $(CC) $(CFLAGS) -o $@ $^
git-%: %.c $(LIB_FILE)
$(CC) $(CFLAGS) -o $@ $(filter %.c,$^) $(LIBS)
@@ -148,6 +141,47 @@ git-rev-list: LIBS += -lssl
$(LIB_OBJS): $(LIB_H)
$(DIFF_OBJS): diffcore.h
+$(LIB_FILE): $(LIB_OBJS)
+ $(AR) rcs $@ $(LIB_OBJS)
+
+doc:
+ $(MAKE) -C Documentation all
+
+
+
+### Testing rules
+
+test: all
+ $(MAKE) -C t/ all
+
+test-date: test-date.c date.o
+ $(CC) $(CFLAGS) -o $@ test-date.c date.o
+
+test-delta: test-delta.c diff-delta.o patch-delta.o
+ $(CC) $(CFLAGS) -o $@ $^
+
+check:
+ for i in *.c; do sparse $(CFLAGS) $(SPARSE_FLAGS) $$i; done
+
+
+
+### Installation rules
+
+install: $(PROG) $(SCRIPTS)
+ $(INSTALL) -m755 -d $(dest)$(bindir)
+ $(INSTALL) $(PROG) $(SCRIPTS) $(dest)$(bin)
+
+install-tools:
+ $(MAKE) -C tools install
+
+install-doc:
+ $(MAKE) -C Documentation install
+
+
+
+
+### Maintainer's dist rules
+
git-core.spec: git-core.spec.in Makefile
sed -e 's/@@VERSION@@/$(GIT_VERSION)/g' < $< > $@
@@ -163,23 +197,16 @@ dist: git-core.spec git-tar-tree
rpm: dist
$(RPMBUILD) -ta git-core-$(GIT_VERSION).tar.gz
-test: all
- $(MAKE) -C t/ all
-doc:
- $(MAKE) -C Documentation all
+backup: clean
+ cd .. ; tar czvf dircache.tar.gz dir-cache
-install-tools:
- $(MAKE) -C tools install
-install-doc:
- $(MAKE) -C Documentation install
+
+### Cleaning rules
clean:
rm -f *.o mozilla-sha1/*.o ppc/*.o $(PROG) $(LIB_FILE)
rm -f git-core-*.tar.gz git-core.spec
$(MAKE) -C tools/ clean
$(MAKE) -C Documentation/ clean
-
-backup: clean
- cd .. ; tar czvf dircache.tar.gz dir-cache
^ permalink raw reply
* [PATCH 7/2] Support for NO_OPENSSL
From: Petr Baudis @ 2005-07-29 15:50 UTC (permalink / raw)
To: junkio; +Cc: git
In-Reply-To: <20050729085819.GL24895@pasky.ji.cz>
Support for completely OpenSSL-less builds. FSF considers distributing GPL
binaries with OpenSSL linked in as a legal problem so this is trouble
e.g. for Debian, or some people might not want to install OpenSSL
anyway. If you
make NO_OPENSSL=1
you get completely OpenSSL-less build, disabling --merge-order and using
Mozilla's SHA1 implementation.
Ported from Cogito.
Signed-off-by: Petr Baudis <pasky@ucw.cz>
---
commit cd2182ac0e0635faeca6467b68decf8ab9625f4c
tree d0c704c203d2319a77cd8fd9ee8fda8adc2d27b4
parent 656a66fe63898954dbc40854dd049dc76eb9b841
author Petr Baudis <pasky@suse.cz> Fri, 29 Jul 2005 17:42:32 +0200
committer Petr Baudis <xpasky@machine.sinus.cz> Fri, 29 Jul 2005 17:42:32 +0200
Makefile | 8 +++++++-
rev-list.c | 6 +++++-
2 files changed, 12 insertions(+), 2 deletions(-)
diff --git a/Makefile b/Makefile
--- a/Makefile
+++ b/Makefile
@@ -83,7 +83,7 @@ LIB_H=cache.h object.h blob.h tree.h com
pack.h pkt-line.h refs.h
LIB_OBJS=read-cache.o sha1_file.o usage.o object.o commit.o tree.o blob.o \
tag.o date.o index.o diff-delta.o patch-delta.o entry.o path.o \
- epoch.o refs.o csum-file.o pack-check.o pkt-line.o connect.o ident.o
+ refs.o csum-file.o pack-check.o pkt-line.o connect.o ident.o
LIB_H += rev-cache.h
LIB_OBJS += rev-cache.o
@@ -105,6 +105,12 @@ LIB_OBJS += server-info.o
LIBS = $(LIB_FILE)
LIBS += -lz
+ifndef NO_OPENSSL
+ LIB_OBJS += epoch.o
+else
+ CFLAGS += '-DNO_OPENSSL'
+ MOZILLA_SHA1=1
+endif
ifdef MOZILLA_SHA1
SHA1_HEADER="mozilla-sha1/sha1.h"
LIB_OBJS += mozilla-sha1/sha1.o
diff --git a/rev-list.c b/rev-list.c
--- a/rev-list.c
+++ b/rev-list.c
@@ -537,9 +537,13 @@ int main(int argc, char **argv)
sort_in_topological_order(&list);
show_commit_list(list);
} else {
+#ifndef NO_OPENSSL
if (sort_list_in_merge_order(list, &process_commit)) {
- die("merge order sort failed\n");
+ die("merge order sort failed\n");
}
+#else
+ die("merge order sort unsupported, OpenSSL not linked");
+#endif
}
return 0;
^ permalink raw reply
* Re: [PACKAGERS] Makefile: DESTDIR vs. dest
From: Joel Becker @ 2005-07-29 16:42 UTC (permalink / raw)
To: Petr Baudis; +Cc: git
In-Reply-To: <20050729133015.GC21909@pasky.ji.cz>
On Fri, Jul 29, 2005 at 03:30:15PM +0200, Petr Baudis wrote:
> git has $dest in its Makefile while Cogito uses $DESTDIR. I'd like to
> ask the potential users of those variables (probably mostly distribution
> package maintainers) what's easier for them and what do they prefer, as
> I would like to unify this.
DESTDIR is "standardized" by automake. Doesn't make it best,
but does make it expected by a lot of folks.
Joel
--
"In the beginning, the universe was created. This has made a lot
of people very angry, and is generally considered to have been a
bad move."
- Douglas Adams
Joel Becker
Senior Member of Technical Staff
Oracle
E-mail: joel.becker@oracle.com
Phone: (650) 506-8127
^ permalink raw reply
* [PATCH 8/2] Build commands through object files
From: Petr Baudis @ 2005-07-29 17:21 UTC (permalink / raw)
To: junkio; +Cc: git
In-Reply-To: <20050729085819.GL24895@pasky.ji.cz>
Separate the process of building the commands to compilation and
linkage. This makes it more consistent with the library objects, is the
traditional thing to do, and significantly speeds up the subsequent
rebuilds, especially for us the people who develop git on 300MHz
notebooks.
Ported from Cogito.
Signed-off-by: Petr Baudis <pasky@ucw.cz>
---
commit 02074521a74483bec941ceacea35f92b485ebd48
tree b08deb01bab982b846b5757943571d0c39b9ba76
parent cd2182ac0e0635faeca6467b68decf8ab9625f4c
author Petr Baudis <pasky@suse.cz> Fri, 29 Jul 2005 19:20:28 +0200
committer Petr Baudis <xpasky@machine.sinus.cz> Fri, 29 Jul 2005 19:20:28 +0200
Makefile | 15 ++++++++-------
1 files changed, 8 insertions(+), 7 deletions(-)
diff --git a/Makefile b/Makefile
--- a/Makefile
+++ b/Makefile
@@ -133,13 +133,14 @@ CFLAGS += '-DSHA1_HEADER=$(SHA1_HEADER)'
all: $(PROG)
-git-%: %.c $(LIB_FILE)
- $(CC) $(CFLAGS) -o $@ $(filter %.c,$^) $(LIBS)
-
-git-http-pull: pull.c
-git-local-pull: pull.c
-git-ssh-pull: rsh.c pull.c
-git-ssh-push: rsh.c
+.PRECIOUS: %.o
+git-%: %.o $(LIB_FILE)
+ $(CC) $(CFLAGS) -o $@ $(filter %.o,$^) $(LIBS)
+
+git-http-pull: pull.o
+git-local-pull: pull.o
+git-ssh-pull: rsh.o pull.o
+git-ssh-push: rsh.o
git-http-pull: LIBS += -lcurl
git-rev-list: LIBS += -lssl
^ permalink raw reply
* [PATCH] document git-rev-list better
From: Matthias Urlichs @ 2005-07-29 18:10 UTC (permalink / raw)
To: git
Document new (and not-so-new) flags of git-rev-list.
Signed-off-By: Matthias Urlichs <smurf@smurf.noris.de>
---
diff --git a/Documentation/git-rev-list.txt b/Documentation/git-rev-list.txt
--- a/Documentation/git-rev-list.txt
+++ b/Documentation/git-rev-list.txt
@@ -9,14 +9,35 @@ git-rev-list - Lists commit objects in r
SYNOPSIS
--------
-'git-rev-list' [ *--max-count*=number ] [ *--max-age*=timestamp ] [ *--min-age*=timestamp ] [ *--merge-order* [ *--show-breaks* ] ] <commit>
+'git-rev-list' [ *--max-count*=number ] [ *--max-age*=timestamp ] [ *--min-age*=timestamp ] [ *--bisect* ] [ *--pretty* ] [ *--objects* ] [ *--merge-order* [ *--show-breaks* ] ] <commit> [ <commit> ...] [ ^<commit> ...]
DESCRIPTION
-----------
Lists commit objects in reverse chronological order starting at the
-given commit, taking ancestry relationship into account. This is
+given commit(s), taking ancestry relationship into account. This is
useful to produce human-readable log output.
+Commits which are stated with a preceding '^' cause listing to stop at
+that point. Their parents are implied. "git-rev-list foo bar ^baz" thus
+means "list all the commits which are included in 'foo' and 'bar', but
+not in 'baz'".
+
+If *--pretty* is specified, print the contents of the commit changesets
+in human-readable form.
+
+The *--objects* flag causes 'git-rev-list' to print the object IDs of
+any object referenced by the listed commits. 'git-rev-list --objects foo
+^bar' thus means "send me all object IDs which I need to download if
+I have the commit object 'bar', but not 'foo'".
+
+The *--bisect* flag limits output to the one commit object which is
+roughly halfway between the included and excluded commits. Thus,
+if "git-rev-list --bisect foo ^bar ^baz" outputs 'midpoint', the output
+of "git-rev-list foo ^midpoint" and "git-rev-list midpoint ^bar ^baz"
+would be of roughly the same length. Finding the change which introduces
+a regression is thus reduced to a binary search: repeatedly generate and
+test new 'midpoint's until the commit chain is of length one.
+
If *--merge-order* is specified, the commit history is decomposed into a
unique sequence of minimal, non-linear epochs and maximal, linear epochs.
Non-linear epochs are then linearised by sorting them into merge order, which
^ permalink raw reply
* Re: [PATCH 4/2] Improve the compilation-time settings interface
From: Petr Baudis @ 2005-07-29 18:23 UTC (permalink / raw)
To: junkio; +Cc: git
In-Reply-To: <20050729154826.GG21909@pasky.ji.cz>
Dear diary, on Fri, Jul 29, 2005 at 05:48:26PM CEST, I got a letter
where Petr Baudis <pasky@suse.cz> told me that...
> diff --git a/Makefile b/Makefile
> --- a/Makefile
> +++ b/Makefile
> @@ -1,33 +1,53 @@
> +# Define NO_OPENSSL environment variable if you do not have OpenSSL. You will
> +# miss out git-rev-list --merge-order. This also implies MOZILLA_SHA1.
Sorry for this, I didn't realize until much later that NO_OPENSSL wasn't
actually in git yet. I hope I won't have to resend the patches just
because of this. :-)
--
Petr "Pasky" Baudis
Stuff: http://pasky.or.cz/
If you want the holes in your knowledge showing up try teaching
someone. -- Alan Cox
^ permalink raw reply
* Re: Git 1.0 Synopis (Draft v3
From: Sam Ravnborg @ 2005-07-29 21:26 UTC (permalink / raw)
To: Ryan Anderson; +Cc: git
In-Reply-To: <20050729082941.GD32263@mythryan2.michonline.com>
On Fri, Jul 29, 2005 at 04:29:41AM -0400, Ryan Anderson wrote:
> Source Code Management with Git
....
The article should include a HOWTO part alos. So people can see how to
edit a file, pull from a remote repository etc.
Since you have introduced core and porcelains it would be most logical
to use one of the porcelains in these examples, maybe accompanied by the
raw git commands being executed.
Sam
^ permalink raw reply
* Re: Last mile to 1.0?
From: Petr Baudis @ 2005-07-29 22:41 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vwtnqhcfb.fsf@assigned-by-dhcp.cox.net>
Dear diary, on Sat, Jul 16, 2005 at 07:46:00PM CEST, I got a letter
where Junio C Hamano <junkio@cox.net> told me that...
> I do not know what release plan Linus has in mind, and also
> expect things to be quieter next week during OLS and kernel
> summit, but I think we are getting really really close.
>
> Here are the things I think we would want to see before we hit
> 1.0:
>
> - Remaining feature enhancements and fixes.
>
> - Anonymous pull from packed archives on remote sites via
> non-rsync, non-ssh transport. Many people are behind
> corporate firewalls that do not pass anything but outgoing
> http(s) and some do not even pass outgoing ssh. The recent
> addition of git-daemon by Linus would greatly alleviate the
> situation, but we may also end up wanting something HTTP
> reachable.
I hope to get to it tomorrow but it now occurred to me that I don't know
when do you actually want to release 1.0 and I think it's crucial for it
to support some sensible HTTP transport - I saw some scripts going in
etc, but what's its current state? Is it usable?
Note that I really _loved_ the Daniel's tools while they lasted. What I
loved most about them was that they really only pulled objects I needed
and not a single worthless one. Does the current HTTP transport share
this property?
> - Publicity. I would be very happy to see somebody with good
> writing and summarizing skills to prepare an article to be
> published on LWN.NET to coincide with the 1.0 release. An
> update to GIT traffic would also be nice.
Note that I also want to setup a simple "proof-of-concept" GIT homepage
tomorrow. Well, write it, where it should be hosted can be worked out
later and I have places for it to reside at for now. (Suggestions for
final hosting welcome. In reality, how nice (and persistent) the URL
gets is probably the only thing that really matters. My attempt will
live at http://git.or.cz/.)
--
Petr "Pasky" Baudis
Stuff: http://pasky.or.cz/
If you want the holes in your knowledge showing up try teaching
someone. -- Alan Cox
^ permalink raw reply
* Fix interesting git-rev-list corner case
From: Linus Torvalds @ 2005-07-29 22:50 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Git Mailing List
This corner-case was triggered by a kernel commit that was not in date
order, due to a misconfigured time zone that made the commit appear three
hours older than it was.
That caused git-rev-list to traverse the commit tree in a non-obvious
order, and made it parse several of the _parents_ of the misplaced commit
before it actually parsed the commit itself. That's fine, but it meant
that the grandparents of the commit didn't get marked uninteresting,
because they had been reached through an "interesting" branch.
The reason was that "mark_parents_uninteresting()" (which is supposed to
mark all existing parents as being uninteresting - duh) didn't actually
traverse more than one level down the parent chain.
NORMALLY this is fine, since with the date-based traversal order,
grandparents won't ever even have been looked at before their parents (so
traversing the chain down isn't needed, because the next time around when
we pick out the parent we'll mark _its_ parents uninteresting), but since
we'd gotten out of order, we'd already seen the parent and thus never got
around to mark the grandparents.
Anyway, the fix is simple. Just traverse parent chains recursively.
Normally the chain won't even exist (since the parent hasn't been parsed
yet), so this is not actually going to trigger except in this strange
corner-case.
Add a comment to the simple one-liner, since this was a bit subtle, and I
had to really think things through to understand how it could happen.
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
---
diff --git a/rev-list.c b/rev-list.c
--- a/rev-list.c
+++ b/rev-list.c
@@ -228,6 +228,17 @@ static void mark_parents_uninteresting(s
commit->object.flags |= UNINTERESTING;
/*
+ * Normally we haven't parsed the parent
+ * yet, so we won't have a parent of a parent
+ * here. However, it may turn out that we've
+ * reached this commit some other way (where it
+ * wasn't uninteresting), in which case we need
+ * to mark its parents recursively too..
+ */
+ if (commit->parents)
+ mark_parents_uninteresting(commit);
+
+ /*
* A missing commit is ok iff its parent is marked
* uninteresting.
*
^ permalink raw reply
* Re: How is working on arbitrary remote heads supposed to work in Cogito (+ PATCH)?
From: Matthias Urlichs @ 2005-07-29 20:40 UTC (permalink / raw)
To: git
In-Reply-To: <7vek9igfgw.fsf@assigned-by-dhcp.cox.net>
Hi, Junio C Hamano wrote:
> Porcelain can keep track of
> mapping between b00:b24 for you,
Exactly.
> but you still need to keep
> track of b00:XYZ and b24:XYZ mapping in your head.
This is why I name my local branch "XYZ". ;-)
XYZ may not be an appropriate name for the remote branch, or maybe the
remote repo is *not* under my direct control, e.g. a shared-master style
setup.
--
Matthias Urlichs | {M:U} IT Design @ m-u-it.de | smurf@smurf.noris.de
Disclaimer: The quote was selected randomly. Really. | http://smurf.noris.de
- -
:munch: vt. [often confused with {mung}, q.v.] To transform information
in a serial fashion, often requiring large amounts of computation. To
trace down a data structure. Related to {crunch} and nearly synonymous
with {grovel}, but connotes less pain.
^ permalink raw reply
* Re: Fix interesting git-rev-list corner case
From: Ryan Anderson @ 2005-07-30 0:11 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Junio C Hamano, Git Mailing List
In-Reply-To: <Pine.LNX.4.58.0507291542060.29650@g5.osdl.org>
On Fri, Jul 29, 2005 at 03:50:30PM -0700, Linus Torvalds wrote:
>
> This corner-case was triggered by a kernel commit that was not in date
> order, due to a misconfigured time zone that made the commit appear three
> hours older than it was.
Maybe it'd make sense to have the commits refuse to add a commit when it
would be younger than one of it's parents?
I suppose that only really fixes one direction of the other problem,
though.
--
Ryan Anderson
sometimes Pug Majere
^ permalink raw reply
* Re: Fix interesting git-rev-list corner case
From: A Large Angry SCM @ 2005-07-30 1:08 UTC (permalink / raw)
To: Ryan Anderson; +Cc: Linus Torvalds, Junio C Hamano, Git Mailing List
In-Reply-To: <20050730001158.GF32263@mythryan2.michonline.com>
Ryan Anderson wrote:
> Maybe it'd make sense to have the commits refuse to add a commit when it
> would be younger than one of it's parents?
Better not to trust timestamps in distributed federations since you
can't guarantee any kind of accuracy across administrative boundaries.
^ permalink raw reply
* Re: Fix interesting git-rev-list corner case
From: Linus Torvalds @ 2005-07-30 1:20 UTC (permalink / raw)
To: Ryan Anderson; +Cc: Junio C Hamano, Git Mailing List
In-Reply-To: <20050730001158.GF32263@mythryan2.michonline.com>
On Fri, 29 Jul 2005, Ryan Anderson wrote:
>
> Maybe it'd make sense to have the commits refuse to add a commit when it
> would be younger than one of it's parents?
No, the git-rev-list thing really was a bug, it was just that I hadn't
thought things through when I wrote it, and the "normal" case (ie the ones
I had tested) just happened to work because it's a common one.
In other words - I had taken a shortcut without thinking it through.
The date really isn't important - the algorithm I had works fine even if
dates are totally screwed up, it just had a stupid bug.
And trying to make the date more important than it is will just inevitably
lead to _worse_ problems down the road.
So the date is a good heuristic (we have to traverse the commits in _some_
order, and the date order just happens to be one that ends up giving the
minimum number of commits "usually"), but any time we _depend_ on dates
one way or the other that would be a good.
Linus
^ permalink raw reply
* Re: Fix interesting git-rev-list corner case
From: Linus Torvalds @ 2005-07-30 1:28 UTC (permalink / raw)
To: Ryan Anderson; +Cc: Junio C Hamano, Git Mailing List
In-Reply-To: <Pine.LNX.4.58.0507291816060.29650@g5.osdl.org>
On Fri, 29 Jul 2005, Linus Torvalds wrote:
>
> , but any time we _depend_ on dates
> one way or the other that would be a good.
"_not_ be a good _thing_". I don't know what strange brain-glitch I had
there.
I had kind of hoped my kids would be all grown up before their dad started
losing his marbles. Oh, well..
Linus
^ permalink raw reply
* Re: [PATCH 3/2] git-merge-cache -q doesn't complain about failing merge program
From: Junio C Hamano @ 2005-07-30 2:11 UTC (permalink / raw)
To: Petr Baudis; +Cc: junkio, git
In-Reply-To: <20050729125338.GB21909@pasky.ji.cz>
Petr Baudis <pasky@suse.cz> writes:
> git-merge-cache reporting failed merge program is undesirable for
> Cogito, since it emits its own more appropriate error message in that
> case. However, I want to show other possible git-merge-cache error
> messages. So -q will just silence this particular error.
That description makes it sound more like it is a Cogito
specific hack, which other Porcelains may not benefit from,
meaning they may want to suppress some other errors but this
patch does not give that possibility.
I do not mind about the above too much, but I'll sit on this one
for now just in case if anybody comes up with a different patch
to give a bit cleaner solution.
I wonder how many die()'s we have in our C code. It _might_ be
cleaner to say (the first parameter being exit(2) parameter):
die("unable to execute '%s'", pgm);
die_with(47, "merge program failed");
and have the calling Porcelain, if it wants to, supress error
messages by redirecting 2>/dev/null, and say whatever it wants
to say based on $?.
^ permalink raw reply
* Re: [PATCH 2/2] Unify usage strings declaration
From: Junio C Hamano @ 2005-07-30 2:11 UTC (permalink / raw)
To: Petr Baudis; +Cc: junkio, git
In-Reply-To: <20050729090126.GN24895@pasky.ji.cz>
Petr Baudis <pasky@suse.cz> writes:
> All usage strings are now declared as static const char [].
I do not have preference either way, and I've already merged
them, but why char[] not char*?
^ permalink raw reply
* Re: Last mile to 1.0?
From: Junio C Hamano @ 2005-07-30 2:11 UTC (permalink / raw)
To: Petr Baudis; +Cc: git
In-Reply-To: <20050729224148.GB22530@pasky.ji.cz>
Petr Baudis <pasky@suse.cz> writes:
> Note that I really _loved_ the Daniel's tools while they lasted. What I
> loved most about them was that they really only pulled objects I needed
> and not a single worthless one. Does the current HTTP transport share
> this property?
I am a big fan of Barkalow puller, too. It is conceptually
simple, very easy to explain, and quite nicely done to be
transport independent. Performance sucks, but that is not Dan's
fault.
If we are talking about a dumb HTTP server that has packed and
then prune-packed its repository, "not a single worthless one"
is asking for moon. If Jeff packed all his 50 branches into a
single pack and prune packed his repository, the only thing a
dumb server could do when you ask for one of his branches is to
give you that statically prepared single pack which contains
everything, because there would be nothing in .git/objects/??/.
You need some CGI support that pulls only needed objects out of
that pack and talks a moral equivalent of the upload-pack
protocol for that.
Barkalow puller is still useful when all the objects you still
need to pull from the remote are unpacked on the remote end.
That's how I resurrected "git clone" over http with packed dumb
servers. For "clone" case, I just slurp all the available
packs, and have Barkalow puller take over the rest.
I have an early WIP for "git fetch", but I have backburnered it
for quite some time. I'll push it in its current form into my
proposed updates branch, so interested people can hack on it.
> Note that I also want to setup a simple "proof-of-concept" GIT homepage
> tomorrow. Well, write it, where it should be hosted can be worked out
> later and I have places for it to reside at for now. (Suggestions for
> final hosting welcome. In reality, how nice (and persistent) the URL
> gets is probably the only thing that really matters. My attempt will
> live at http://git.or.cz/.)
I hope nobody starts another SCM project called CZ ;-).
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox