* [PATCH 2/3] Parallelize the pull algorithm
From: barkalow @ 2005-08-02 23:46 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <Pine.LNX.4.62.0508021939320.23721@iabervon.org>
This processes objects in two simultaneous passes. Each object will
first be given to prefetch(), as soon as it is possible to tell that
it will be needed, and then will be given to fetch(), when it is the
next object that needs to be parsed. Unless an implementation does
something with prefetch(), this should have no effect.
Signed-off-by: Daniel Barkalow <barkalow@iabervon.org>
---
http-pull.c | 4 ++
local-pull.c | 4 ++
pull.c | 132 ++++++++++++++++++++++++++++++++++------------------------
pull.h | 7 +++
ssh-pull.c | 4 ++
5 files changed, 97 insertions(+), 54 deletions(-)
adf8aa039f2db3fb3bfc4dee0a7354b662cd5422
diff --git a/http-pull.c b/http-pull.c
--- a/http-pull.c
+++ b/http-pull.c
@@ -67,6 +67,10 @@ static size_t fwrite_sha1_file(void *ptr
return size;
}
+void prefetch(unsigned char *sha1)
+{
+}
+
static int got_indices = 0;
static struct packed_git *packs = NULL;
diff --git a/local-pull.c b/local-pull.c
--- a/local-pull.c
+++ b/local-pull.c
@@ -11,6 +11,10 @@ static int use_filecopy = 1;
static char *path; /* "Remote" git repository */
+void prefetch(unsigned char *sha1)
+{
+}
+
int fetch(unsigned char *sha1)
{
static int object_name_start = -1;
diff --git a/pull.c b/pull.c
--- a/pull.c
+++ b/pull.c
@@ -17,11 +17,8 @@ int get_all = 0;
int get_verbosely = 0;
static unsigned char current_commit_sha1[20];
-static const char commitS[] = "commit";
-static const char treeS[] = "tree";
-static const char blobS[] = "blob";
-
-void pull_say(const char *fmt, const char *hex) {
+void pull_say(const char *fmt, const char *hex)
+{
if (get_verbosely)
fprintf(stderr, fmt, hex);
}
@@ -48,93 +45,118 @@ static int make_sure_we_have_it(const ch
return status;
}
-static int process_unknown(unsigned char *sha1);
+static int process(unsigned char *sha1, const char *type);
-static int process_tree(unsigned char *sha1)
+static int process_tree(struct tree *tree)
{
- struct tree *tree = lookup_tree(sha1);
struct tree_entry_list *entries;
if (parse_tree(tree))
return -1;
for (entries = tree->entries; entries; entries = entries->next) {
- const char *what = entries->directory ? treeS : blobS;
- if (make_sure_we_have_it(what, entries->item.tree->object.sha1))
+ if (process(entries->item.any->sha1,
+ entries->directory ? tree_type : blob_type))
return -1;
- if (entries->directory) {
- if (process_tree(entries->item.tree->object.sha1))
- return -1;
- }
}
return 0;
}
-static int process_commit(unsigned char *sha1)
+static int process_commit(struct commit *commit)
{
- struct commit *obj = lookup_commit(sha1);
-
- if (make_sure_we_have_it(commitS, sha1))
+ if (parse_commit(commit))
return -1;
- if (parse_commit(obj))
- return -1;
+ memcpy(current_commit_sha1, commit->object.sha1, 20);
if (get_tree) {
- if (make_sure_we_have_it(treeS, obj->tree->object.sha1))
- return -1;
- if (process_tree(obj->tree->object.sha1))
+ if (process(commit->tree->object.sha1, tree_type))
return -1;
if (!get_all)
get_tree = 0;
}
if (get_history) {
- struct commit_list *parents = obj->parents;
+ struct commit_list *parents = commit->parents;
for (; parents; parents = parents->next) {
if (has_sha1_file(parents->item->object.sha1))
continue;
- if (make_sure_we_have_it(NULL,
- parents->item->object.sha1)) {
- /* The server might not have it, and
- * we don't mind.
- */
- continue;
- }
- if (process_commit(parents->item->object.sha1))
+ if (process(parents->item->object.sha1,
+ commit_type))
return -1;
- memcpy(current_commit_sha1, sha1, 20);
}
}
return 0;
}
-static int process_tag(unsigned char *sha1)
+static int process_tag(struct tag *tag)
{
- struct tag *obj = lookup_tag(sha1);
-
- if (parse_tag(obj))
+ if (parse_tag(tag))
return -1;
- return process_unknown(obj->tagged->sha1);
+ return process(tag->tagged->sha1, NULL);
}
-static int process_unknown(unsigned char *sha1)
+static struct object_list *process_queue = NULL;
+static struct object_list **process_queue_end = &process_queue;
+
+static int process(unsigned char *sha1, const char *type)
{
struct object *obj;
- if (make_sure_we_have_it("object", sha1))
- return -1;
- obj = parse_object(sha1);
- if (!obj)
- return error("Unable to parse object %s", sha1_to_hex(sha1));
- if (obj->type == commit_type)
- return process_commit(sha1);
- if (obj->type == tree_type)
- return process_tree(sha1);
- if (obj->type == blob_type)
+ if (has_sha1_file(sha1))
return 0;
- if (obj->type == tag_type)
- return process_tag(sha1);
- return error("Unable to determine requirement of type %s for %s",
- obj->type, sha1_to_hex(sha1));
+ obj = lookup_object_type(sha1, type);
+ if (object_list_contains(process_queue, obj))
+ return 0;
+ object_list_insert(obj, process_queue_end);
+ process_queue_end = &(*process_queue_end)->next;
+
+ //fprintf(stderr, "prefetch %s\n", sha1_to_hex(sha1));
+ prefetch(sha1);
+
+ return 0;
+}
+
+static int loop(void)
+{
+ while (process_queue) {
+ struct object *obj = process_queue->item;
+ /*
+ fprintf(stderr, "%d objects to pull\n",
+ object_list_length(process_queue));
+ */
+ process_queue = process_queue->next;
+ if (!process_queue)
+ process_queue_end = &process_queue;
+
+ //fprintf(stderr, "fetch %s\n", sha1_to_hex(obj->sha1));
+
+ if (make_sure_we_have_it(obj->type ?: "object",
+ obj->sha1))
+ return -1;
+ if (!obj->type)
+ parse_object(obj->sha1);
+ if (obj->type == commit_type) {
+ if (process_commit((struct commit *)obj))
+ return -1;
+ continue;
+ }
+ if (obj->type == tree_type) {
+ if (process_tree((struct tree *)obj))
+ return -1;
+ continue;
+ }
+ if (obj->type == blob_type) {
+ continue;
+ }
+ if (obj->type == tag_type) {
+ if (process_tag((struct tag *)obj))
+ return -1;
+ continue;
+ }
+ return error("Unable to determine requirements "
+ "of type %s for %s",
+ obj->type, sha1_to_hex(obj->sha1));
+ }
+ return 0;
}
static int interpret_target(char *target, unsigned char *sha1)
@@ -164,7 +186,9 @@ int pull(char *target)
if (interpret_target(target, sha1))
return error("Could not interpret %s as something to pull",
target);
- if (process_unknown(sha1))
+ if (process(sha1, NULL))
+ return -1;
+ if (loop())
return -1;
if (write_ref) {
diff --git a/pull.h b/pull.h
--- a/pull.h
+++ b/pull.h
@@ -9,6 +9,13 @@
extern int fetch(unsigned char *sha1);
/*
+ * Fetch the specified object and store it locally; fetch() will be
+ * called later to determine success. To be provided by the particular
+ * implementation.
+ */
+extern void prefetch(unsigned char *sha1);
+
+/*
* Fetch ref (relative to $GIT_DIR/refs) from the remote, and store
* the 20-byte SHA1 in sha1. Return 0 on success, -1 on failure. To
* be provided by the particular implementation.
diff --git a/ssh-pull.c b/ssh-pull.c
--- a/ssh-pull.c
+++ b/ssh-pull.c
@@ -10,6 +10,10 @@ static int fd_out;
static unsigned char remote_version = 0;
static unsigned char local_version = 1;
+void prefetch(unsigned char *sha1)
+{
+}
+
int fetch(unsigned char *sha1)
{
int ret;
^ permalink raw reply
* [PATCH 3/3] Parallelize pulling by ssh
From: barkalow @ 2005-08-02 23:46 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <Pine.LNX.4.62.0508021939320.23721@iabervon.org>
This causes ssh-pull to request objects in prefetch() and read then in
fetch(), such that it reduces the unpipelined round-trip time.
This also makes sha1_write_from_fd() support having a buffer of data
which it accidentally read from the fd after the object; this was
formerly not a problem, because it would always get a short read at
the end of an object, because the next object had not been
requested. This is no longer true.
Signed-off-by: Daniel Barkalow <barkalow@iabervon.org>
---
cache.h | 3 ++-
sha1_file.c | 37 ++++++++++++++++++++++---------------
ssh-pull.c | 44 ++++++++++++++++++++++++++++++++++++--------
3 files changed, 60 insertions(+), 24 deletions(-)
9bd15230cb65acc78a97550c9467f98a04720ee8
diff --git a/cache.h b/cache.h
--- a/cache.h
+++ b/cache.h
@@ -198,7 +198,8 @@ extern int check_sha1_signature(const un
/* Read a tree into the cache */
extern int read_tree(void *buffer, unsigned long size, int stage, const char **paths);
-extern int write_sha1_from_fd(const unsigned char *sha1, int fd);
+extern int write_sha1_from_fd(const unsigned char *sha1, int fd, char *buffer,
+ size_t bufsize, size_t *bufposn);
extern int write_sha1_to_fd(int fd, const unsigned char *sha1);
extern int has_sha1_pack(const unsigned char *sha1);
diff --git a/sha1_file.c b/sha1_file.c
--- a/sha1_file.c
+++ b/sha1_file.c
@@ -1389,14 +1389,14 @@ int write_sha1_to_fd(int fd, const unsig
return 0;
}
-int write_sha1_from_fd(const unsigned char *sha1, int fd)
+int write_sha1_from_fd(const unsigned char *sha1, int fd, char *buffer,
+ size_t bufsize, size_t *bufposn)
{
char *filename = sha1_file_name(sha1);
int local;
z_stream stream;
unsigned char real_sha1[20];
- unsigned char buf[4096];
unsigned char discard[4096];
int ret;
SHA_CTX c;
@@ -1414,7 +1414,24 @@ int write_sha1_from_fd(const unsigned ch
do {
ssize_t size;
- size = read(fd, buf, 4096);
+ if (*bufposn) {
+ stream.avail_in = *bufposn;
+ stream.next_in = buffer;
+ do {
+ stream.next_out = discard;
+ stream.avail_out = sizeof(discard);
+ ret = inflate(&stream, Z_SYNC_FLUSH);
+ SHA1_Update(&c, discard, sizeof(discard) -
+ stream.avail_out);
+ } while (stream.avail_in && ret == Z_OK);
+ write(local, buffer, *bufposn - stream.avail_in);
+ memmove(buffer, buffer + *bufposn - stream.avail_in,
+ stream.avail_in);
+ *bufposn = stream.avail_in;
+ if (ret != Z_OK)
+ break;
+ }
+ size = read(fd, buffer + *bufposn, bufsize - *bufposn);
if (size <= 0) {
close(local);
unlink(filename);
@@ -1423,18 +1440,8 @@ int write_sha1_from_fd(const unsigned ch
perror("Reading from connection");
return -1;
}
- write(local, buf, size);
- stream.avail_in = size;
- stream.next_in = buf;
- do {
- stream.next_out = discard;
- stream.avail_out = sizeof(discard);
- ret = inflate(&stream, Z_SYNC_FLUSH);
- SHA1_Update(&c, discard, sizeof(discard) -
- stream.avail_out);
- } while (stream.avail_in && ret == Z_OK);
-
- } while (ret == Z_OK);
+ *bufposn += size;
+ } while (1);
inflateEnd(&stream);
close(local);
diff --git a/ssh-pull.c b/ssh-pull.c
--- a/ssh-pull.c
+++ b/ssh-pull.c
@@ -10,24 +10,49 @@ static int fd_out;
static unsigned char remote_version = 0;
static unsigned char local_version = 1;
+ssize_t force_write(int fd, void *buffer, size_t length)
+{
+ ssize_t ret = 0;
+ while (ret < length) {
+ ssize_t size = write(fd, buffer + ret, length - ret);
+ if (size < 0) {
+ return size;
+ }
+ if (size == 0) {
+ return ret;
+ }
+ ret += size;
+ }
+ return ret;
+}
+
void prefetch(unsigned char *sha1)
{
+ char type = 'o';
+ force_write(fd_out, &type, 1);
+ force_write(fd_out, sha1, 20);
+ //memcpy(requested + 20 * prefetches++, sha1, 20);
}
+static char conn_buf[4096];
+static size_t conn_buf_posn = 0;
+
int fetch(unsigned char *sha1)
{
int ret;
signed char remote;
- char type = 'o';
- if (has_sha1_file(sha1))
- return 0;
- write(fd_out, &type, 1);
- write(fd_out, sha1, 20);
- if (read(fd_in, &remote, 1) < 1)
- return -1;
+
+ if (conn_buf_posn) {
+ remote = conn_buf[0];
+ memmove(conn_buf, conn_buf + 1, --conn_buf_posn);
+ } else {
+ if (read(fd_in, &remote, 1) < 1)
+ return -1;
+ }
+ //fprintf(stderr, "Got %d\n", remote);
if (remote < 0)
return remote;
- ret = write_sha1_from_fd(sha1, fd_in);
+ ret = write_sha1_from_fd(sha1, fd_in, conn_buf, 4096, &conn_buf_posn);
if (!ret)
pull_say("got %s\n", sha1_to_hex(sha1));
return ret;
^ permalink raw reply
* Re: [PATCH 1/3] Add git-send-email-script - tool to send emails from git-format-patch-script
From: Ryan Anderson @ 2005-08-03 1:30 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vbr4jmhqe.fsf@assigned-by-dhcp.cox.net>
On Sun, Jul 31, 2005 at 02:45:29AM -0700, Junio C Hamano wrote:
> Ryan Anderson <ryan@michonline.com> writes:
>
> > All emails are sent as a reply to the previous email, making it easy to
> > skip a collection of emails that are uninteresting.
>
> I understand why _some_ people consider this preferable, but
> wonder if this should have a knob to be tweaked.
>
> For example, I myself often find it very hard to read when
> a cascading thread goes very deep like this:
>
> [PATCH 0/9] cover
> [PATCH 1/9] first one
> [PATCH 2/9] second one
> [PATCH 3/9] third one in the series
> ...
>
> and prefer to see this instead (this assumes your MUA is
> half-way decent and lets you sort by subject):
>
> [PATCH 0/9] cover
> [PATCH 1/9] first one
> [PATCH 2/9] second one
> [PATCH 3/9] third one in the series
> ...
In testing this, I think I figured out *why* the former is preferred -
it guarantees the sorting when in the standard mode of "order by date".
Since these emails are sent *very* fast, delivery order tends to be the
dominating factor in how they sort in your inbox, as they will all have
the same time. So that's a trifle annoying.
Yes, sorting by subject will fix it, but "threaded + subject" is
actually something I'm not sure much of anything supports. (It's not
instantly obvious how to do it in mutt, for example - though,
admittedly, Mutt may very well have a way to do it.)
I noticed this while testing my 2 new fixes - those will sent in a few
seconds.
--
Ryan Anderson
sometimes Pug Majere
^ permalink raw reply
* [PATCH 2/2] Doc: update git-send-email-script documentation.
From: Ryan Anderson @ 2005-08-03 1:45 UTC (permalink / raw)
To: Junio C Hamano, git; +Cc: Ryan Anderson
In-Reply-To: <1123033522656-git-send-email-ryan@michonline.com>
Signed-off-by: Ryan Anderson <ryan@michonline.com>
---
Documentation/git-send-email-script.txt | 13 +++++++++++++
1 files changed, 13 insertions(+), 0 deletions(-)
b09788cd193a52bb44ab39826c9c6959f79305d5
diff --git a/Documentation/git-send-email-script.txt b/Documentation/git-send-email-script.txt
--- a/Documentation/git-send-email-script.txt
+++ b/Documentation/git-send-email-script.txt
@@ -44,6 +44,19 @@ The options available are:
to set this to a space. For example
--in-reply-to=" "
+ --chain-reply-to, --no-chain-reply-to
+ If this is set, each email will be sent as a reply to the previous
+ email sent. If disabled with "--no-chain-reply-to", all emails after
+ the first will be sent as replies to the first email sent. When using
+ this, it is recommended that the first file given be an overview of the
+ entire patch series.
+ Default is --chain-reply-to
+
+ --smtp-server
+ If set, specifies the outgoing SMTP server to use. Defaults to
+ localhost.
+
+
Author
------
Written by Ryan Anderson <ryan@michonline.com>
^ permalink raw reply
* [PATCH 1/2] git-send-email-script - Fix loops that limit emails to unique values to be pedantically correct.
From: Ryan Anderson @ 2005-08-03 1:45 UTC (permalink / raw)
To: Junio C Hamano, git; +Cc: Ryan Anderson
Email addresses aren't generally case sensitive in the real world, but
technically, they *can* be. So, let's do the right thing.
Additionally, fix the generated message-id to have the right template used.
Signed-off-by: Ryan Anderson <ryan@michonline.com>
---
git-send-email-script | 35 ++++++++++++++++++++++++-----------
1 files changed, 24 insertions(+), 11 deletions(-)
8e791ded8877746b82432f2b53f871197a3c3901
diff --git a/git-send-email-script b/git-send-email-script
--- a/git-send-email-script
+++ b/git-send-email-script
@@ -24,6 +24,8 @@ use Getopt::Long;
use Data::Dumper;
use Email::Valid;
+sub unique_email_list(@);
+
# Variables we fill in automatically, or via prompting:
my (@to,@cc,$initial_reply_to,$initial_subject,@files,$from);
@@ -138,8 +140,9 @@ Options:
--to Specify the primary "To:" line of the email.
--subject Specify the initial "Subject:" line.
--in-reply-to Specify the first "In-Reply-To:" header line.
- --chain-reply-to If set, the replies will all be to the first
- email sent, rather than to the last email sent.
+ --chain-reply-to If set, the replies will all be to the previous
+ email sent, rather than to the first email sent.
+ Defaults to on.
--smtp-server If set, specifies the outgoing SMTP server to use.
Defaults to localhost.
@@ -161,7 +164,7 @@ our ($message_id, $cc, %mail, $subject,
# We'll setup a template for the message id, using the "from" address:
my $message_id_from = Email::Valid->address($from);
-my $message_id_template = "<%s-git-send-email-$from>";
+my $message_id_template = "<%s-git-send-email-$message_id_from>";
sub make_message_id
{
@@ -178,10 +181,7 @@ $cc = "";
sub send_message
{
- my %to;
- $to{lc(Email::Valid->address($_))}++ for (@to);
-
- my $to = join(",", keys %to);
+ my $to = join (", ", unique_email_list(@to));
%mail = ( To => $to,
From => $from,
@@ -267,10 +267,7 @@ foreach my $t (@files) {
}
close F;
- my %clean_ccs;
- $clean_ccs{lc(Email::Valid->address($_))}++ for @cc;
-
- $cc = join(",", keys %clean_ccs);
+ $cc = join(", ", unique_email_list(@cc));
send_message();
@@ -281,3 +278,19 @@ foreach my $t (@files) {
make_message_id();
# $subject = "Re: ".$initial_subject;
}
+
+
+sub unique_email_list(@) {
+ my %seen;
+ my @emails;
+
+ foreach my $entry (@_) {
+ my $clean = Email::Valid->address($entry);
+ next if $seen{$clean}++;
+ push @emails, $entry;
+ }
+ return @emails;
+}
+
+
+
^ permalink raw reply
* Re: Users of git-check-files?
From: Linus Torvalds @ 2005-08-03 2:43 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: git
In-Reply-To: <Pine.LNX.4.63.0508030109210.21304@wgmdd8.biozentrum.uni-wuerzburg.de>
On Wed, 3 Aug 2005, Johannes Schindelin wrote:
>
> there's git-check-files in the repository, but AFAIK nobody uses it, not
> even "git status", which would be the primary candidate. If really no
> users of git-check-files exist, maybe we should remove it?
Yes.
It was used by the old "git-applymbox" (aka "dotest") until I got around
writing "git-apply".
It has no point any more, all the tools check the file status on their
own, and yes, the thing should probably be removed.
Linus
^ permalink raw reply
* Re: [patch] list shortlog items in commit order
From: Jeff Garzik @ 2005-08-03 3:58 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Nicolas Pitre, git, Linus Torvalds
In-Reply-To: <7vvf2oklwy.fsf@assigned-by-dhcp.cox.net>
Junio C Hamano wrote:
> Nicolas Pitre <nico@cam.org> writes:
>
>
>>The current shortlog list is backward making it look odd.
>>This reverses it so things appear more logically.
>
>
> Sorry, I do not know how the shortlog looked like in BK days,
> but it would be nice to match that order. I do not have
> preference either way myself.
>
> I'll let it simmer and let the list decide, but I think the
> kernel folks care the most about this one, so I am asking the
> original authors, Linus and Jeff, if they want to go for it, or
> veto it.
<shrug> I don't really care either way.
Jeff
^ permalink raw reply
* Re: [patch] list shortlog items in commit order
From: Linus Torvalds @ 2005-08-03 4:59 UTC (permalink / raw)
To: Jeff Garzik; +Cc: Junio C Hamano, Nicolas Pitre, git
In-Reply-To: <42F040E1.5000706@pobox.com>
On Tue, 2 Aug 2005, Jeff Garzik wrote:
>
> <shrug> I don't really care either way.
I suspect it's mostly the users, not the developers, who care. The core
developers already know what went in, and have git to see it, they don't
look at the shortlog output. So I suspect it's more important to see if
there's user feedback one way or the other..
Linus
^ permalink raw reply
* Re: Users of git-check-files?
From: Junio C Hamano @ 2005-08-03 6:17 UTC (permalink / raw)
To: Linus Torvalds; +Cc: git
In-Reply-To: <Pine.LNX.4.58.0508021942500.3341@g5.osdl.org>
Linus Torvalds <torvalds@osdl.org> writes:
> It has no point any more, all the tools check the file status on their
> own, and yes, the thing should probably be removed.
How about git-rev-tree? Does anybody care?
^ permalink raw reply
* [PATCH] Install sample hooks
From: Junio C Hamano @ 2005-08-03 6:23 UTC (permalink / raw)
To: git
Josef Weidendorfer made a good suggestion to throw in sample
hooks, disabled by default, to newly created repositories. Here
is a proposed patch. I will advance it to the master branch if
I do not hear objections, probably by the end of the week.
------------
A template mechanism to populate newly initialized repository
with default set of files is introduced. Use it to ship example
hooks that can be used for update and post update checks, as
Josef Weidendorfer suggests.
Signed-off-by: Junio C Hamano <junkio@cox.net>
---
Makefile | 5 +
cache.h | 4 +
init-db.c | 142 ++++++++++++++++++++++++++++++++++++++++++
templates/Makefile | 19 ++++++
templates/hooks--post-update | 8 ++
templates/hooks--update | 21 ++++++
6 files changed, 199 insertions(+), 0 deletions(-)
create mode 100644 templates/Makefile
create mode 100644 templates/hooks--post-update
create mode 100644 templates/hooks--update
a03cd67d2ff5dd0cf43a0be53e6f35e4cb684b8e
diff --git a/Makefile b/Makefile
--- a/Makefile
+++ b/Makefile
@@ -39,6 +39,8 @@ CFLAGS+=$(COPTS) -Wall $(DEFINES)
prefix=$(HOME)
bindir=$(prefix)/bin
+etcdir=$(prefix)/etc
+etcgitdir=$(etcdir)/git-core
# dest=
CC?=gcc
@@ -143,6 +145,7 @@ endif
endif
CFLAGS += '-DSHA1_HEADER=$(SHA1_HEADER)'
+CFLAGS += '-DDEFAULT_GIT_TEMPLATE_ENVIRONMENT="$(etcgitdir)/templates"'
@@ -195,6 +198,7 @@ check:
install: $(PROG) $(SCRIPTS)
$(INSTALL) -m755 -d $(dest)$(bindir)
$(INSTALL) $(PROG) $(SCRIPTS) $(dest)$(bindir)
+ $(MAKE) -C templates install
install-tools:
$(MAKE) -C tools install
@@ -235,4 +239,5 @@ clean:
rm -f git-core-*.tar.gz git-core.spec
$(MAKE) -C tools/ clean
$(MAKE) -C Documentation/ clean
+ $(MAKE) -C templates/ clean
$(MAKE) -C t/ clean
diff --git a/cache.h b/cache.h
--- a/cache.h
+++ b/cache.h
@@ -128,6 +128,10 @@ extern unsigned int active_nr, active_al
#define DB_ENVIRONMENT "GIT_OBJECT_DIRECTORY"
#define INDEX_ENVIRONMENT "GIT_INDEX_FILE"
#define GRAFT_ENVIRONMENT "GIT_GRAFT_FILE"
+#define TEMPLATE_DIR_ENVIRONMENT "GIT_TEMPLATE_DIRECTORY"
+#ifndef DEFAULT_GIT_TEMPLATE_ENVIRONMENT
+#define DEFAULT_GIT_TEMPLATE_ENVIRONMENT "/etc/git-core/templates"
+#endif
extern char *get_object_directory(void);
extern char *get_refs_directory(void);
diff --git a/init-db.c b/init-db.c
--- a/init-db.c
+++ b/init-db.c
@@ -15,6 +15,147 @@ static void safe_create_dir(const char *
}
}
+static int copy_file(const char *dst, const char *src, int mode)
+{
+ int fdi, fdo;
+
+ mode = (mode & 0111) ? 0777 : 0666;
+ if ((fdi = open(src, O_RDONLY)) < 0)
+ return fdi;
+ if ((fdo = open(dst, O_WRONLY | O_CREAT | O_EXCL, mode)) < 0) {
+ close(fdi);
+ return fdo;
+ }
+ while (1) {
+ char buf[BUFSIZ];
+ ssize_t leni, leno, ofs;
+ leni = read(fdi, buf, sizeof(buf));
+ if (leni < 0) {
+ error_return:
+ close(fdo);
+ close(fdi);
+ return -1;
+ }
+ if (!leni)
+ break;
+ ofs = 0;
+ do {
+ leno = write(fdo, buf+ofs, leni);
+ if (leno < 0)
+ goto error_return;
+ leni -= leno;
+ ofs += leno;
+ } while (0 < leni);
+ }
+ close(fdo);
+ close(fdi);
+ return 0;
+}
+
+static void copy_templates_1(char *path, int baselen,
+ char *template, int template_baselen,
+ DIR *dir)
+{
+ struct dirent *de;
+
+ /* Note: if ".git/hooks" file exists in the repository being
+ * re-initialized, /etc/core-git/templates/hooks/update would
+ * cause git-init-db to fail here. I think this is sane but
+ * it means that the set of templates we ship by default, along
+ * with the way the namespace under .git/ is organized, should
+ * be really carefully chosen.
+ */
+ safe_create_dir(path);
+ while ((de = readdir(dir)) != NULL) {
+ struct stat st_git, st_template;
+ int namelen;
+ int exists = 0;
+
+ if (de->d_name[0] == '.')
+ continue;
+ namelen = strlen(de->d_name);
+ if ((PATH_MAX <= baselen + namelen) ||
+ (PATH_MAX <= template_baselen + namelen))
+ die("insanely long template name %s", de->d_name);
+ memcpy(path + baselen, de->d_name, namelen+1);
+ memcpy(template + template_baselen, de->d_name, namelen+1);
+ if (lstat(path, &st_git)) {
+ if (errno != ENOENT)
+ die("cannot stat %s", path);
+ }
+ else
+ exists = 1;
+
+ if (lstat(template, &st_template))
+ die("cannot stat template %s", template);
+
+ if (S_ISDIR(st_template.st_mode)) {
+ DIR *subdir = opendir(template);
+ int baselen_sub = baselen + namelen;
+ int template_baselen_sub = template_baselen + namelen;
+ if (!subdir)
+ die("cannot opendir %s", template);
+ path[baselen_sub++] =
+ template[template_baselen_sub++] = '/';
+ path[baselen_sub] =
+ template[template_baselen_sub] = 0;
+ copy_templates_1(path, baselen_sub,
+ template, template_baselen_sub,
+ subdir);
+ closedir(subdir);
+ }
+ else if (exists)
+ continue;
+ else if (S_ISLNK(st_template.st_mode)) {
+ char lnk[256];
+ int len;
+ len = readlink(template, lnk, sizeof(lnk));
+ if (len < 0)
+ die("cannot readlink %s", template);
+ if (sizeof(lnk) <= len)
+ die("insanely long symlink %s", template);
+ lnk[len] = 0;
+ if (symlink(lnk, path))
+ die("cannot symlink %s %s", lnk, path);
+ }
+ else if (S_ISREG(st_template.st_mode)) {
+ if (copy_file(path, template, st_template.st_mode))
+ die("cannot copy %s to %s", template, path);
+ }
+ else
+ error("ignoring template %s", template);
+ }
+}
+
+static void copy_templates(const char *git_dir)
+{
+ char path[PATH_MAX];
+ char template_path[PATH_MAX];
+ char *template_dir;
+ int len, template_len;
+ DIR *dir;
+
+ strcpy(path, git_dir);
+ len = strlen(path);
+ template_dir = gitenv(TEMPLATE_DIR_ENVIRONMENT);
+ if (!template_dir)
+ template_dir = DEFAULT_GIT_TEMPLATE_ENVIRONMENT;
+ strcpy(template_path, template_dir);
+ template_len = strlen(template_path);
+ if (template_path[template_len-1] != '/') {
+ template_path[template_len++] = '/';
+ template_path[template_len] = 0;
+ }
+
+ dir = opendir(template_path);
+ if (!dir)
+ return;
+ copy_templates_1(path, len,
+ template_path, template_len,
+ dir);
+ closedir(dir);
+}
+
static void create_default_files(const char *git_dir)
{
unsigned len = strlen(git_dir);
@@ -48,6 +189,7 @@ static void create_default_files(const c
exit(1);
}
}
+ copy_templates(path);
}
/*
diff --git a/templates/Makefile b/templates/Makefile
new file mode 100644
--- /dev/null
+++ b/templates/Makefile
@@ -0,0 +1,19 @@
+# make
+
+INSTALL=install
+prefix=$(HOME)
+etcdir=$(prefix)/etc
+etcgitdir=$(etcdir)/git-core
+templatedir=$(etcgitdir)/templates
+# dest=
+
+all:
+clean:
+
+install:
+ $(INSTALL) -d -m755 $(dest)$(templatedir)/hooks/
+ $(foreach s,$(wildcard hooks--*),\
+ $(INSTALL) -m644 $s \
+ $(dest)$(templatedir)/hooks/$(patsubst hooks--%,%,$s);)
+ $(INSTALL) -d -m755 $(dest)$(templatedir)/info
+ $(INSTALL) -d -m755 $(dest)$(templatedir)/branches
diff --git a/templates/hooks--post-update b/templates/hooks--post-update
new file mode 100644
--- /dev/null
+++ b/templates/hooks--post-update
@@ -0,0 +1,8 @@
+#!/bin/sh
+#
+# An example hook script to prepare a packed repository for use over
+# dumb transports.
+#
+# To enable this hook, make this file executable by "chmod +x post-update".
+
+exec git-update-server-info
diff --git a/templates/hooks--update b/templates/hooks--update
new file mode 100644
--- /dev/null
+++ b/templates/hooks--update
@@ -0,0 +1,21 @@
+#!/bin/sh
+#
+# An example hook script to mail out commit update information.
+#
+# To enable this hook:
+# (1) change the recipient e-mail address
+# (2) make this file executable by "chmod +x update".
+#
+
+recipient="commit-list@mydomain.xz"
+
+if expr "$2" : '0*$' >/dev/null
+then
+ echo "Created a new ref, with the following commits:"
+ git-rev-list --pretty "$2"
+else
+ echo "New commits:"
+ git-rev-list --pretty "$3" "^$2"
+fi |
+mail -s "Changes to ref $1" "$recipient"
+exit 0
^ permalink raw reply
* [PATCH] daemon.c: squelch error message from EINTR
From: Junio C Hamano @ 2005-08-03 6:20 UTC (permalink / raw)
To: git
This is a "call for help" patch. The kernel.org folks are
talking about installing git daemon, and while the problem I am
trying to address should not matter when the daemon is spawned
from inetd, I would like to get this resolved. Help greatly
apprciated.
-jc
------------
It appears that every time after servicing the connection,
select() first fails with EINTR and ends up waiting for one
second before serving the next client. The sleep() was placed
by the original author per suggestion from the list to avoid
spinning on failing select, but at least this EINTR situation
should not result in "at most one client per second" service
limit.
I am not sure if this is the right fix, and I have not received
an answer from the original author of the patch. I would
appreciate help from the folks on the list who are familiar with
the networking.
Signed-off-by: Junio C Hamano <junkio@cox.net>
---
daemon.c | 7 +++++--
1 files changed, 5 insertions(+), 2 deletions(-)
34be43e7af874923cfa1c8baeaf19fa17bae4d30
diff --git a/daemon.c b/daemon.c
--- a/daemon.c
+++ b/daemon.c
@@ -294,8 +294,11 @@ static int serve(int port)
fds = fds_init;
if (select(maxfd + 1, &fds, NULL, NULL, NULL) < 0) {
- error("select failed, resuming: %s", strerror(errno));
- sleep(1);
+ if (errno != EINTR) {
+ error("select failed, resuming: %s",
+ strerror(errno));
+ sleep(1);
+ }
continue;
}
^ permalink raw reply
* [PATCH] Use the template mechanism to set up refs/ hierarchy as well.
From: Junio C Hamano @ 2005-08-03 6:28 UTC (permalink / raw)
To: git
This may be controversial from the robustness standpoint, so I
am placing it in the proposed update queue first. Discussions
on the list very welcomed.
Once the alternate object pool mechanism is taught to use
$GIT_DIR/info/alt file (instead of/in addition to the
environment variable), this would help people setting up
repositories for underling developers. They can prepare a
standard template info/alt that points at the project-wide base
object pool that is shared, and have people point
GIT_TEMPLATE_DIRECTORY at the project standard template
directory.
------------
This removes the hardcoded set of refs/ directory structure that
is created by git-init-db and move it to the template
mechanism.
Signed-off-by: Junio C Hamano <junkio@cox.net>
---
init-db.c | 22 ----------------------
t/t5400-send-pack.sh | 16 +++++++++++++++-
templates/Makefile | 4 ++++
3 files changed, 19 insertions(+), 23 deletions(-)
de8b5bf5605274d29b835947932b9b6c109f5d9f
diff --git a/init-db.c b/init-db.c
--- a/init-db.c
+++ b/init-db.c
@@ -167,28 +167,6 @@ static void create_default_files(const c
if (len && path[len-1] != '/')
path[len++] = '/';
-
- /*
- * Create .git/refs/{heads,tags}
- */
- strcpy(path + len, "refs");
- safe_create_dir(path);
- strcpy(path + len, "refs/heads");
- safe_create_dir(path);
- strcpy(path + len, "refs/tags");
- safe_create_dir(path);
-
- /*
- * Create the default symlink from ".git/HEAD" to the "master"
- * branch
- */
- strcpy(path + len, "HEAD");
- if (symlink("refs/heads/master", path) < 0) {
- if (errno != EEXIST) {
- perror(path);
- exit(1);
- }
- }
copy_templates(path);
}
diff --git a/t/t5400-send-pack.sh b/t/t5400-send-pack.sh
--- a/t/t5400-send-pack.sh
+++ b/t/t5400-send-pack.sh
@@ -8,6 +8,18 @@ test_description='See why rewinding head
'
. ./test-lib.sh
+# This part is needed to test before installing templates.
+mkdir -p templates/refs/heads
+ln -s refs/heads/master templates/HEAD
+mkdir -p templates/hooks
+echo '#!/bin/sh
+echo we are here >$GIT_DIR/we-are-here' >templates/hooks/post-update
+chmod +x templates/hooks/post-update
+
+GIT_TEMPLATE_DIRECTORY=`pwd`/templates/
+export GIT_TEMPLATE_DIRECTORY
+git-init-db
+
cnt='1'
test_expect_success setup '
tree=$(git-write-tree) &&
@@ -50,5 +62,7 @@ test_expect_success \
fi &&
# this should update
git-send-pack --force ./victim/.git/ master &&
- cmp victim/.git/refs/heads/master .git/refs/heads/master
+ cmp victim/.git/refs/heads/master .git/refs/heads/master &&
+ # and post-update should have run
+ test -f victim/.git/we-are-here
'
diff --git a/templates/Makefile b/templates/Makefile
--- a/templates/Makefile
+++ b/templates/Makefile
@@ -17,3 +17,7 @@ install:
$(dest)$(templatedir)/hooks/$(patsubst hooks--%,%,$s);)
$(INSTALL) -d -m755 $(dest)$(templatedir)/info
$(INSTALL) -d -m755 $(dest)$(templatedir)/branches
+ $(INSTALL) -d -m755 $(dest)$(templatedir)/refs/heads
+ $(INSTALL) -d -m755 $(dest)$(templatedir)/refs/tags
+ rm -f $(dest)$(templatedir)/HEAD && \
+ ln -s refs/heads/master $(dest)$(templatedir)/HEAD
^ permalink raw reply
* Re: [PATCH 1/3] Add git-send-email-script - tool to send emails from git-format-patch-script
From: Matthias Urlichs @ 2005-08-03 7:32 UTC (permalink / raw)
To: git
In-Reply-To: <20050803013042.GF5762@mythryan2.michonline.com>
Hi, Ryan Anderson wrote:
> Since these emails are sent *very* fast, delivery order tends to be the
> dominating factor in how they sort in your inbox, as they will all have
> the same time. So that's a trifle annoying.
That's trivially fixable: just generate your own Date: header and
add a second for each email.
--
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
- -
Be careful whilst playing under the anvil tree.
^ permalink raw reply
* cogito: problems in read-only trees
From: Wolfgang Denk @ 2005-08-03 7:42 UTC (permalink / raw)
To: git
Hello,
sometimes I have to work in trees for which I have only read
permissions; cogito has problems then - for example:
-> cg-diff
fatal: unable to create new cachefile
fatal: unable to create temp-file
It would be nice if there was at least a way to specify some TMPDIR
instead of the current directory in such a situation.
Best regards,
Wolfgang Denk
--
Software Engineering: Embedded and Realtime Systems, Embedded Linux
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd@denx.de
Include the success of others in your dreams for your own success.
^ permalink raw reply
* Re: Email patch -> git commit?
From: Catalin Marinas @ 2005-08-03 8:47 UTC (permalink / raw)
To: H. Peter Anvin; +Cc: Git Mailing List
In-Reply-To: <42EFF077.6080606@zytor.com>
"H. Peter Anvin" <hpa@zytor.com> wrote:
> Anyone have any good scripts for taking patches in email and turning
> them into git commits, preferrably while preserving the author
> information?
StGIT can do this as well, via the 'stg import -m' command. You will
see it as a GIT commit (with 'git log') as well as an StGIT patch. It
preserves the author information taken from the From: line (can be
overwritten with command line options).
--
Catalin
^ permalink raw reply
* [PATCH] Plug memory leaks in git-unpack-objects
From: Sergey Vlasov @ 2005-08-03 12:11 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
[-- Attachment #1: Type: text/plain, Size: 1206 bytes --]
- Call inflateEnd to release zlib state after use.
- After resolving delta, free base object data.
Signed-off-by: Sergey Vlasov <vsu@altlinux.ru>
---
unpack-objects.c | 6 +++++-
1 files changed, 5 insertions(+), 1 deletions(-)
890ab530c0c0aad5c070690498d3b1254c7a30bc
diff --git a/unpack-objects.c b/unpack-objects.c
--- a/unpack-objects.c
+++ b/unpack-objects.c
@@ -75,6 +75,7 @@ static void *get_data(unsigned long size
stream.next_in = fill(1);
stream.avail_in = len;
}
+ inflateEnd(&stream);
return buf;
}
@@ -167,6 +168,7 @@ static int unpack_delta_entry(unsigned l
unsigned long base_size;
char type[20];
unsigned char base_sha1[20];
+ int result;
memcpy(base_sha1, fill(20), 20);
use(20);
@@ -184,7 +186,9 @@ static int unpack_delta_entry(unsigned l
base = read_sha1_file(base_sha1, type, &base_size);
if (!base)
die("failed to read delta-pack base object %s", sha1_to_hex(base_sha1));
- return resolve_delta(type, base, base_size, delta_data, delta_size);
+ result = resolve_delta(type, base, base_size, delta_data, delta_size);
+ free(base);
+ return result;
}
static void unpack_one(unsigned nr, unsigned total)
[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: Users of git-check-files?
From: Johannes Schindelin @ 2005-08-03 14:21 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Linus Torvalds, git
In-Reply-To: <7vvf2nk0h7.fsf@assigned-by-dhcp.cox.net>
Hi,
On Tue, 2 Aug 2005, Junio C Hamano wrote:
> Linus Torvalds <torvalds@osdl.org> writes:
>
>> It has no point any more, all the tools check the file status on their
>> own, and yes, the thing should probably be removed.
>
> How about git-rev-tree? Does anybody care?
I try to write a "git annotate" based on the output of git-whatchanged.
Since git-whatchanged only shows the commit and its parent, I need to
figure out what was the last diff that led to the current commit's state.
This needs git-rev-tree.
Ciao,
Dscho
P.S.: My only unsolved problem is that git-whatchanged sometimes shows
the diffs in the wrong order (clock-skew problem?)
^ permalink raw reply
* Re: Users of git-check-files?
From: Linus Torvalds @ 2005-08-03 15:09 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vvf2nk0h7.fsf@assigned-by-dhcp.cox.net>
On Tue, 2 Aug 2005, Junio C Hamano wrote:
>
> How about git-rev-tree? Does anybody care?
Yeah, probably not. git-rev-list does so much more than git-rev-tree ever
did.
Linus
^ permalink raw reply
* [PATCH] GIT_SSH alternate ssh name or helper
From: Martin Sivak @ 2005-08-03 15:15 UTC (permalink / raw)
To: git
[-- Attachment #1: Type: text/plain, Size: 1827 bytes --]
This patch make possible to use alternate ssh binary or ssh helper
script. The script can be used to give additional parameters to ssh
binary (like private key, protocol version, ...).
Example script could look like this:
#!/bin/sh
ssh -1 -i myprivatekey.key "$@"
The patch itself is realy very simple:
diff -uNr git-current/connect.c git-current-mars@nomi.cz/connect.c
--- git-current/connect.c 2005-08-03 15:00:04.000000000 +0200
+++ git-current-mars@nomi.cz/connect.c 2005-08-03 16:32:36.000000000 +0200
@@ -166,6 +166,9 @@
int pipefd[2][2];
pid_t pid;
enum protocol protocol;
+ char *sshprog;
+
+ sshprog = getenv("GIT_SSH") ? : "ssh";
host = NULL;
path = url;
@@ -205,7 +208,7 @@
close(pipefd[1][0]);
close(pipefd[1][1]);
if (protocol == PROTO_SSH)
- execlp("ssh", "ssh", host, command, NULL);
+ execlp(sshprog, "ssh", host, command, NULL);
else
execlp("sh", "sh", "-c", command, NULL);
die("exec failed");
diff -uNr git-current/rsh.c git-current-mars@nomi.cz/rsh.c
--- git-current/rsh.c 2005-08-03 15:00:04.000000000 +0200
+++ git-current-mars@nomi.cz/rsh.c 2005-08-03 16:26:39.000000000 +0200
@@ -17,6 +17,7 @@
char command[COMMAND_SIZE];
char *posn;
int i;
+ char *prog;
if (!strcmp(url, "-")) {
*fd_in = 0;
@@ -24,6 +25,8 @@
return 0;
}
+ prog = getenv("GIT_SSH") ? : "ssh";
+
host = strstr(url, "//");
if (host) {
host += 2;
@@ -59,7 +62,7 @@
close(sv[1]);
dup2(sv[0], 0);
dup2(sv[0], 1);
- execlp("ssh", "ssh", host, command, NULL);
+ execlp(prog, "ssh", host, command, NULL);
}
close(sv[0]);
*fd_in = sv[1];
Signed-off-by: Martin Sivak <mars@nomi.cz>
--
Martin Sivak
mars@nomi.cz
[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: Users of git-check-files?
From: Junio C Hamano @ 2005-08-03 15:51 UTC (permalink / raw)
To: Linus Torvalds; +Cc: git
In-Reply-To: <Pine.LNX.4.58.0508030808530.3341@g5.osdl.org>
Linus Torvalds <torvalds@osdl.org> writes:
> Yeah, probably not. git-rev-list does so much more than git-rev-tree ever
> did.
Does rev-list do --edges ;-)?
BTW, I have two known bugs/problems that I haven't resolved,
which is bothering me quite a bit. Yes, it is my fault (lack of
time and concentration). One is the EINTR from the daemon.c,
and another is receive-pack failing with "unpack should have
generated but I cannot find it" when pushing. The latter is
something "I am aware of, I know it needs to be diagnosed, but I
have not looked into yet".
^ permalink raw reply
* Re: Users of git-check-files?
From: Linus Torvalds @ 2005-08-03 16:17 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vr7dbhvci.fsf@assigned-by-dhcp.cox.net>
On Wed, 3 Aug 2005, Junio C Hamano wrote:
>
> Linus Torvalds <torvalds@osdl.org> writes:
>
> > Yeah, probably not. git-rev-list does so much more than git-rev-tree ever
> > did.
>
> Does rev-list do --edges ;-)?
No, but does anybody use it? It _may_ be interesting as a git-merge-base
thing, but then we should probably add it to git-merge-base (which
actually _does_ do edges these days, but it just only shows the most
recent one..)
> BTW, I have two known bugs/problems that I haven't resolved,
> which is bothering me quite a bit. Yes, it is my fault (lack of
> time and concentration). One is the EINTR from the daemon.c,
I actually think the new code is totally broken. If you want to listen to
several sockets, you should just run several daemons. Yeah, yeah, it won't
give you "global child control" etc, but I doubt we care.
But I don't think it's a huge issue, since most serious users are likely
to use the "--inetd" flag and use inetd as the real daemon anyway (ie the
built-in daemon code is most useful for normal users just setting up
their own quick thing).
> and another is receive-pack failing with "unpack should have
> generated but I cannot find it" when pushing. The latter is
> something "I am aware of, I know it needs to be diagnosed, but I
> have not looked into yet".
I've lost that state. Can you explain a bit mroe..
Linus
^ permalink raw reply
* Re: Users of git-check-files?
From: Junio C Hamano @ 2005-08-03 16:36 UTC (permalink / raw)
To: Linus Torvalds; +Cc: git
In-Reply-To: <Pine.LNX.4.58.0508030913060.3341@g5.osdl.org>
Linus Torvalds <torvalds@osdl.org> writes:
> I've lost that state. Can you explain a bit mroe..
Sorry, you have not lost anything. It is my bad that this is
the first time I brought it up. I've been seeing that from time
to time when I push to either my "send to master" repository
from my working repository, or from the "send to master"
repository to master.kernel.org, but I haven't figured it out if
there is any pattern. It's one of those "I'll try to take a
snapshot so I can have a reproduction recipe to figure it out
next time it happens" things. Unfortunately, when it happens
against master.kernel.org, I have more urgent task of making
sure that the public repository is not in any way corrupted, and
after fixing that (it typically takes removing the
git.git/refs/{master,pu} and repushing, which recovers fine), I
do not have much to start trying to reproduce it anymore X-<.
^ permalink raw reply
* Re: Users of git-check-files?
From: Johannes Schindelin @ 2005-08-03 16:46 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Linus Torvalds, git
In-Reply-To: <7vk6j3f044.fsf@assigned-by-dhcp.cox.net>
Hi,
On Wed, 3 Aug 2005, Junio C Hamano wrote:
> Sorry, you have not lost anything. It is my bad that this is
> the first time I brought it up. I've been seeing that from time
> to time when I push to either my "send to master" repository
> from my working repository, or from the "send to master"
> repository to master.kernel.org, but I haven't figured it out if
> there is any pattern.
This could be related to what I was realizing the other day: when trying
to push to a repository (just one branch), but I do not have _all_ of the
remote branches pulled, then it fails.
Ciao,
Dscho
^ permalink raw reply
* Re: Users of git-check-files?
From: Linus Torvalds @ 2005-08-03 16:45 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vk6j3f044.fsf@assigned-by-dhcp.cox.net>
On Wed, 3 Aug 2005, Junio C Hamano wrote:
>
> Linus Torvalds <torvalds@osdl.org> writes:
>
> > I've lost that state. Can you explain a bit mroe..
>
> Sorry, you have not lost anything. It is my bad that this is
> the first time I brought it up. I've been seeing that from time
> to time when I push to either my "send to master" repository
> from my working repository, or from the "send to master"
> repository to master.kernel.org, but I haven't figured it out if
> there is any pattern.
Are you sure you have a good git version on master? I've never seen
anything like that, and I push all the time..
Linus
^ permalink raw reply
* Re: Users of git-check-files?
From: Johannes Schindelin @ 2005-08-03 16:50 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Junio C Hamano, git
In-Reply-To: <Pine.LNX.4.58.0508030944210.3258@g5.osdl.org>
Hi,
On Wed, 3 Aug 2005, Linus Torvalds wrote:
> Are you sure you have a good git version on master? I've never seen
> anything like that, and I push all the time..
Call him Zaphod: he has two heads (master and pu). You don't. As I said in
another mail, this could be very well related to Junio's problems.
Ciao,
Dscho
^ 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