* Re: [CORRECTED PATCH] git-fetch-pack: avoid unnecessary zero packing
From: Linus Torvalds @ 2005-10-18 20:38 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Git Mailing List
In-Reply-To: <7vmzl6r78e.fsf@assigned-by-dhcp.cox.net>
On Tue, 18 Oct 2005, Junio C Hamano wrote:
>
> It strikes me that we could walk from our refs, depth reasonably
> limited to say 20 or so commit chain and/or last 5 days of
> commit time, to see if any of the remotes are reachable from our
> refs and omit issuing "want" quite cheaply. Do you think that
> would be a worthy change to make things more efficient?
Probably doesn't make a huge difference, but it might be worth trying.
There's a cheap test you can do _before_ you even start walking: check if
you have the object that is pointed to by the remote ref at all. If you
don't have it, then you know it can't be reachable from any of the local
refs. And if you do have it, the likelihood that it _is_ reachable is
likely pretty high.
(I didn't do that for the current fetch-pack optimization, since just
doing the read_ref() is likely faster than even bothering with the object
lookup. But if you start traversing commit lists, it suddenly becomes
more worthwhile).
You'd need to look up the object anyway in order to figure out that it's a
commit (or points to a commit).
So it might be wasting a bit of time, but the good news is that it wastes
time on the _client_ side, where we've got plenty.
I'll see if I can come up with a good patch.
Linus
^ permalink raw reply
* Re: [PATCH] Typo fixes.
From: Petr Baudis @ 2005-10-18 20:31 UTC (permalink / raw)
To: Pavel Roskin; +Cc: git
In-Reply-To: <1129352364.16454.1.camel@dv>
Dear diary, on Sat, Oct 15, 2005 at 06:59:24AM CEST, I got a letter
where Pavel Roskin <proski@gnu.org> told me that...
> Signed-off-by: Pavel Roskin <proski@gnu.org>
Thanks. Applied except for the cancelled -> canceled changes, I like
"cancelled" better - I'm used to it, so I would probably use it again
anyway, and at any rate it seems more regular.
--
Petr "Pasky" Baudis
Stuff: http://pasky.or.cz/
VI has two modes: the one in which it beeps and the one in which
it doesn't.
^ permalink raw reply
* Hard-linked trees with git?
From: Krzysztof Halasa @ 2005-10-18 20:18 UTC (permalink / raw)
To: git
Hi,
Are hard-linked working trees possible with git? Anybody doing that?
Or: is it possible to have some constant file timestamps, so that
changing the HEAD to something and returning to the old HEAD
(say, with hard resets) restores the old timestamps?
--
Krzysztof Halasa
^ permalink raw reply
* git-diff-tree rename detection for single file
From: David Ho @ 2005-10-18 19:56 UTC (permalink / raw)
To: git
Hi,
I have a small suggestion to make the diff of a renamed file a bit
more meaningful. I have a file that is renamed-edited and commited.
git-diff-tree -M -p <commit> shows one result and git-diff-tree -M -p
<commit> <filename> shows another. If they both show a rename
occurred then I think the single file git-diff-tree will be more
useful.
Any strange idea I have is to make git-diff-tree traverse the list of
commits (assuming the list is returned from git-rev-list) to trace
renames of the file to its origin. Of course I don't know how useful
this is to most.
David
[davidho@penguin git-tutorial]$ git-diff-tree -r -M -p \
8c77fe87790276b4e0b2650d7c5799eb893ac3ed
8c77fe87790276b4e0b2650d7c5799eb893ac3ed
diff --git a/goodbye b/ciao
similarity index 83%
rename from goodbye
rename to ciao
index 0561cce..d8259f5 100644
--- a/goodbye
+++ b/ciao
@@ -4,3 +4,4 @@ Play, play, play
Work, work, work
Eat, eat, eat
Drink, drink, drink
+Chew, chew, chew
[davidho@penguin git-tutorial]$ git-diff-tree -r -M -p \
8c77fe87790276b4e0b2650d7c5799eb893ac3ed ciao
8c77fe87790276b4e0b2650d7c5799eb893ac3ed
diff --git a/ciao b/ciao
new file mode 100644
index 0000000..d8259f5
--- /dev/null
+++ b/ciao
@@ -0,0 +1,7 @@
+Hello World
+It's a new day for git
+Play, play, play
+Work, work, work
+Eat, eat, eat
+Drink, drink, drink
+Chew, chew, chew
^ permalink raw reply related
* git-daemon enabled on kernel.org
From: H. Peter Anvin @ 2005-10-18 19:30 UTC (permalink / raw)
To: Git Mailing List
After getting gitweb behind mod_cache, the load on kernel.org has gotten
down into the tolerable range, so I have enabled git-daemon in an
attempt to fix that :)
The URL, obviously, is git://git.kernel.org/pub/scm/...
(or, to specify a specific server, git1.kernel.org or git2.kernel.org.)
I consider this experimental so far, and if it imposes an unacceptable
load I'll have to disable it. It currently runs with an inetd-imposed
limits of 10 instances per server.
-hpa
^ permalink raw reply
* Re: [CORRECTED PATCH] git-fetch-pack: avoid unnecessary zero packing
From: Junio C Hamano @ 2005-10-18 19:19 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vmzl6r78e.fsf@assigned-by-dhcp.cox.net>
Junio C Hamano <junkio@cox.net> writes:
> No, I haven't (not my git day today).
>
> It strikes me that we could walk from our refs, depth reasonably
> limited to say 20 or so commit chain and/or last 5 days of
> commit time, to see if any of the remotes are reachable from our
> refs and omit issuing "want" quite cheaply. Do you think that
> would be a worthy change to make things more efficient?
Something like this on top of your second patch?
------------
Subject: do not ask for objects known to be complete.
On top of optimization by Linus not to ask refs that already
match, we can shallowly walk our refs and not issue "want" for
things that we know are reachable from them.
Signed-off-by: Junio C Hamano <junkio@cox.net>
---
diff --git a/fetch-pack.c b/fetch-pack.c
index 4597369..212e00f 100644
--- a/fetch-pack.c
+++ b/fetch-pack.c
@@ -1,6 +1,9 @@
#include "cache.h"
#include "refs.h"
#include "pkt-line.h"
+#include "commit.h"
+#include "tag.h"
+#include <time.h>
#include <sys/wait.h>
static int quiet;
@@ -78,16 +81,58 @@ static int find_common(int fd[2], unsign
return retval;
}
+#define COMPLETE (1U << 0)
+
+/*
+ * 5 days - this should be configurable.
+ */
+#define RECENT (5 * 24 * 60 * 60)
+
+static struct commit_list *complete = NULL;
+
+static int mark_complete(const char *path, const unsigned char *sha1)
+{
+ struct object *o = parse_object(sha1);
+
+ while (o && o->type == tag_type) {
+ o->flags |= COMPLETE;
+ o = parse_object(((struct tag *)o)->tagged->sha1);
+ }
+ if (o->type == commit_type) {
+ struct commit *commit = (struct commit *)o;
+ commit->object.flags |= COMPLETE;
+ insert_by_date(commit, &complete);
+ }
+ return 0;
+}
+
+static void mark_recent_complete_commits(unsigned long cutoff_date)
+{
+ while (complete && cutoff_date <= complete->item->date) {
+ if (verbose)
+ fprintf(stderr, "Marking %s as complete\n",
+ sha1_to_hex(complete->item->object.sha1));
+ pop_most_recent_commit(&complete, COMPLETE);
+ }
+}
+
static int everything_local(struct ref *refs)
{
int retval;
+ time_t now;
+
+ time(&now);
+
+ for_each_ref(mark_complete);
+ mark_recent_complete_commits((unsigned long) now - RECENT);
for (retval = 1; refs ; refs = refs->next) {
const unsigned char *remote = refs->old_sha1;
unsigned char local[20];
+ struct object *o;
- if (read_ref(git_path("%s", refs->name), local) < 0 ||
- memcmp(remote, local, 20)) {
+ o = parse_object(remote);
+ if (!o || !(o->flags & COMPLETE)) {
retval = 0;
if (!verbose)
continue;
^ permalink raw reply related
* Re: [CORRECTED PATCH] git-fetch-pack: avoid unnecessary zero packing
From: Junio C Hamano @ 2005-10-18 18:49 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Git Mailing List
In-Reply-To: <Pine.LNX.4.64.0510181049050.17201@g5.osdl.org>
Linus Torvalds <torvalds@osdl.org> writes:
> Ok, this should be the trivially fixed (famous last words) patch, which
> should correct the case where we don't have a local name for the remote
> ref at all.
>
> If you already applied the previous patch, you just need to fix the
No, I haven't (not my git day today).
It strikes me that we could walk from our refs, depth reasonably
limited to say 20 or so commit chain and/or last 5 days of
commit time, to see if any of the remotes are reachable from our
refs and omit issuing "want" quite cheaply. Do you think that
would be a worthy change to make things more efficient?
^ permalink raw reply
* Re: [CORRECTED PATCH] git-fetch-pack: avoid unnecessary zero packing
From: Junio C Hamano @ 2005-10-18 18:45 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Git Mailing List
In-Reply-To: <Pine.LNX.4.64.0510181049050.17201@g5.osdl.org>
Linus Torvalds <torvalds@osdl.org> writes:
> If everything is up-to-date locally, we don't need to even ask for a
> pack-file from the remote, or try to unpack it.
>
> This is especially important for tags - since the pack-file common commit
> logic is based purely on the commit history, it will never be able to find
> a common tag, and will thus always end up re-fetching them.
>
> Especially notably, if the tag points to a non-commit (eg a tagged tree),
> the pack-file would be unnecessarily big, just because it cannot any most
> recent common point between commits for pruning.
>
> Short-circuiting the case where we already have that reference means that
> we avoid a lot of these in the common case.
>
> NOTE! This only matches remote ref names against the same local name,
> which works well for tags, but is not as generic as it could be. If we
> ever need to, we could match against _any_ local ref (if we have it, we
> have it), but this "match against same name" is simpler and more
> efficient, and covers the common case.
>
> Renaming of refs is common for branch heads, but since those are always
> commits, the pack-file generation can optimize that case.
>
> In some cases we might still end up fetching pack-files unnecessarily, but
> this at least avoids the re-fetching of tags over and over if you use a
> regular
>
> git fetch --tags ...
>
> which was the main reason behind the change.
>
> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
> ---
>
> Ok, this should be the trivially fixed (famous last words) patch, which
> should correct the case where we don't have a local name for the remote
> ref at all.
>
> If you already applied the previous patch, you just need to fix the
>
> if (read_ref(...) < 0)
> continue
> if (memcmp(..)) {
>
> to be one case (a failing read_ref should do the exact same thing as a
> failed memcmp):
>
> if (read_ref(...) < 0 ||
> memcmp(...) {
>
> and everything should be ok.
>
> This has gotten _some_ testing, but obviously not enough ;)
>
> Linus
>
> diff --git a/fetch-pack.c b/fetch-pack.c
> index 953c0cf..4597369 100644
> --- a/fetch-pack.c
> +++ b/fetch-pack.c
> @@ -12,6 +12,7 @@ static const char *exec = "git-upload-pa
> static int find_common(int fd[2], unsigned char *result_sha1,
> struct ref *refs)
> {
> + int fetching;
> static char line[1000];
> int count = 0, flushes = 0, retval;
> FILE *revs;
> @@ -20,16 +21,19 @@ static int find_common(int fd[2], unsign
> if (!revs)
> die("unable to run 'git-rev-list'");
>
> - while (refs) {
> + fetching = 0;
> + for ( ; refs ; refs = refs->next) {
> unsigned char *remote = refs->old_sha1;
> - if (verbose)
> - fprintf(stderr,
> - "want %s (%s)\n", sha1_to_hex(remote),
> - refs->name);
> + unsigned char *local = refs->new_sha1;
> +
> + if (!memcmp(remote, local, 20))
> + continue;
> packet_write(fd[1], "want %s\n", sha1_to_hex(remote));
> - refs = refs->next;
> + fetching++;
> }
> packet_flush(fd[1]);
> + if (!fetching)
> + return 1;
> flushes = 1;
> retval = -1;
> while (fgets(line, sizeof(line), revs) != NULL) {
> @@ -74,6 +78,35 @@ static int find_common(int fd[2], unsign
> return retval;
> }
>
> +static int everything_local(struct ref *refs)
> +{
> + int retval;
> +
> + for (retval = 1; refs ; refs = refs->next) {
> + const unsigned char *remote = refs->old_sha1;
> + unsigned char local[20];
> +
> + if (read_ref(git_path("%s", refs->name), local) < 0 ||
> + memcmp(remote, local, 20)) {
> + retval = 0;
> + if (!verbose)
> + continue;
> + fprintf(stderr,
> + "want %s (%s)\n", sha1_to_hex(remote),
> + refs->name);
> + continue;
> + }
> +
> + memcpy(refs->new_sha1, local, 20);
> + if (!verbose)
> + continue;
> + fprintf(stderr,
> + "already have %s (%s)\n", sha1_to_hex(remote),
> + refs->name);
> + }
> + return retval;
> +}
> +
> static int fetch_pack(int fd[2], int nr_match, char **match)
> {
> struct ref *ref;
> @@ -86,6 +119,10 @@ static int fetch_pack(int fd[2], int nr_
> packet_flush(fd[1]);
> die("no matching remote head");
> }
> + if (everything_local(ref)) {
> + packet_flush(fd[1]);
> + goto all_done;
> + }
> if (find_common(fd, sha1, ref) < 0)
> fprintf(stderr, "warning: no common commits\n");
> pid = fork();
> @@ -109,6 +146,7 @@ static int fetch_pack(int fd[2], int nr_
> int code = WEXITSTATUS(status);
> if (code)
> die("git-unpack-objects died with error code %d", code);
> +all_done:
> while (ref) {
> printf("%s %s\n",
> sha1_to_hex(ref->old_sha1), ref->name);
^ permalink raw reply
* [CORRECTED PATCH] git-fetch-pack: avoid unnecessary zero packing
From: Linus Torvalds @ 2005-10-18 17:52 UTC (permalink / raw)
To: Junio C Hamano, Git Mailing List
If everything is up-to-date locally, we don't need to even ask for a
pack-file from the remote, or try to unpack it.
This is especially important for tags - since the pack-file common commit
logic is based purely on the commit history, it will never be able to find
a common tag, and will thus always end up re-fetching them.
Especially notably, if the tag points to a non-commit (eg a tagged tree),
the pack-file would be unnecessarily big, just because it cannot any most
recent common point between commits for pruning.
Short-circuiting the case where we already have that reference means that
we avoid a lot of these in the common case.
NOTE! This only matches remote ref names against the same local name,
which works well for tags, but is not as generic as it could be. If we
ever need to, we could match against _any_ local ref (if we have it, we
have it), but this "match against same name" is simpler and more
efficient, and covers the common case.
Renaming of refs is common for branch heads, but since those are always
commits, the pack-file generation can optimize that case.
In some cases we might still end up fetching pack-files unnecessarily, but
this at least avoids the re-fetching of tags over and over if you use a
regular
git fetch --tags ...
which was the main reason behind the change.
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
---
Ok, this should be the trivially fixed (famous last words) patch, which
should correct the case where we don't have a local name for the remote
ref at all.
If you already applied the previous patch, you just need to fix the
if (read_ref(...) < 0)
continue
if (memcmp(..)) {
to be one case (a failing read_ref should do the exact same thing as a
failed memcmp):
if (read_ref(...) < 0 ||
memcmp(...) {
and everything should be ok.
This has gotten _some_ testing, but obviously not enough ;)
Linus
diff --git a/fetch-pack.c b/fetch-pack.c
index 953c0cf..4597369 100644
--- a/fetch-pack.c
+++ b/fetch-pack.c
@@ -12,6 +12,7 @@ static const char *exec = "git-upload-pa
static int find_common(int fd[2], unsigned char *result_sha1,
struct ref *refs)
{
+ int fetching;
static char line[1000];
int count = 0, flushes = 0, retval;
FILE *revs;
@@ -20,16 +21,19 @@ static int find_common(int fd[2], unsign
if (!revs)
die("unable to run 'git-rev-list'");
- while (refs) {
+ fetching = 0;
+ for ( ; refs ; refs = refs->next) {
unsigned char *remote = refs->old_sha1;
- if (verbose)
- fprintf(stderr,
- "want %s (%s)\n", sha1_to_hex(remote),
- refs->name);
+ unsigned char *local = refs->new_sha1;
+
+ if (!memcmp(remote, local, 20))
+ continue;
packet_write(fd[1], "want %s\n", sha1_to_hex(remote));
- refs = refs->next;
+ fetching++;
}
packet_flush(fd[1]);
+ if (!fetching)
+ return 1;
flushes = 1;
retval = -1;
while (fgets(line, sizeof(line), revs) != NULL) {
@@ -74,6 +78,35 @@ static int find_common(int fd[2], unsign
return retval;
}
+static int everything_local(struct ref *refs)
+{
+ int retval;
+
+ for (retval = 1; refs ; refs = refs->next) {
+ const unsigned char *remote = refs->old_sha1;
+ unsigned char local[20];
+
+ if (read_ref(git_path("%s", refs->name), local) < 0 ||
+ memcmp(remote, local, 20)) {
+ retval = 0;
+ if (!verbose)
+ continue;
+ fprintf(stderr,
+ "want %s (%s)\n", sha1_to_hex(remote),
+ refs->name);
+ continue;
+ }
+
+ memcpy(refs->new_sha1, local, 20);
+ if (!verbose)
+ continue;
+ fprintf(stderr,
+ "already have %s (%s)\n", sha1_to_hex(remote),
+ refs->name);
+ }
+ return retval;
+}
+
static int fetch_pack(int fd[2], int nr_match, char **match)
{
struct ref *ref;
@@ -86,6 +119,10 @@ static int fetch_pack(int fd[2], int nr_
packet_flush(fd[1]);
die("no matching remote head");
}
+ if (everything_local(ref)) {
+ packet_flush(fd[1]);
+ goto all_done;
+ }
if (find_common(fd, sha1, ref) < 0)
fprintf(stderr, "warning: no common commits\n");
pid = fork();
@@ -109,6 +146,7 @@ static int fetch_pack(int fd[2], int nr_
int code = WEXITSTATUS(status);
if (code)
die("git-unpack-objects died with error code %d", code);
+all_done:
while (ref) {
printf("%s %s\n",
sha1_to_hex(ref->old_sha1), ref->name);
^ permalink raw reply related
* Re: git-fetch-pack: avoid unnecessary zero packing
From: Linus Torvalds @ 2005-10-18 17:48 UTC (permalink / raw)
To: Junio C Hamano, Git Mailing List
In-Reply-To: <Pine.LNX.4.64.0510181032400.3369@g5.osdl.org>
Gaah. Ignore this version - I had re-organized the code, and that
introduced a stupid bug for the case where the local side didn't have any
such ref at all.
I'll send a corrected patch momentarily.
Linus
On Tue, 18 Oct 2005, Linus Torvalds wrote:
>
> If everything is up-to-date locally, we don't need to even ask for a
> pack-file from the remote, or try to unpack it.
^ permalink raw reply
* git-fetch-pack: avoid unnecessary zero packing
From: Linus Torvalds @ 2005-10-18 17:45 UTC (permalink / raw)
To: Junio C Hamano, Git Mailing List
If everything is up-to-date locally, we don't need to even ask for a
pack-file from the remote, or try to unpack it.
This is especially important for tags - since the pack-file common commit
logic is based purely on the commit history, it will never be able to find
a common tag, and will thus always end up re-fetching them.
Especially notably, if the tag points to a non-commit (eg a tagged tree),
the pack-file would be unnecessarily big, just because it cannot any most
recent common point between commits for pruning.
Short-circuiting the case where we already have that reference means that
we avoid a lot of these in the common case.
NOTE! This only matches remote ref names against the same local name,
which works well for tags, but is not as generic as it could be. If we
ever need to, we could match against _any_ local ref (if we have it, we
have it), but this "match against same name" is simpler and more
efficient, and covers the common case.
Renaming of refs is common for branch heads, but since those are always
commits, the pack-file generation can optimize that case.
In some cases we might still end up fetching pack-files unnecessarily, but
this at least avoids the re-fetching of tags over and over if you use a
regular
git fetch --tags ...
which was the main reason behind the change.
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
---
diff --git a/fetch-pack.c b/fetch-pack.c
index 953c0cf..cf21c34 100644
--- a/fetch-pack.c
+++ b/fetch-pack.c
@@ -12,6 +12,7 @@ static const char *exec = "git-upload-pa
static int find_common(int fd[2], unsigned char *result_sha1,
struct ref *refs)
{
+ int fetching;
static char line[1000];
int count = 0, flushes = 0, retval;
FILE *revs;
@@ -20,16 +21,19 @@ static int find_common(int fd[2], unsign
if (!revs)
die("unable to run 'git-rev-list'");
- while (refs) {
+ fetching = 0;
+ for ( ; refs ; refs = refs->next) {
unsigned char *remote = refs->old_sha1;
- if (verbose)
- fprintf(stderr,
- "want %s (%s)\n", sha1_to_hex(remote),
- refs->name);
+ unsigned char *local = refs->new_sha1;
+
+ if (!memcmp(remote, local, 20))
+ continue;
packet_write(fd[1], "want %s\n", sha1_to_hex(remote));
- refs = refs->next;
+ fetching++;
}
packet_flush(fd[1]);
+ if (!fetching)
+ return 1;
flushes = 1;
retval = -1;
while (fgets(line, sizeof(line), revs) != NULL) {
@@ -74,6 +78,37 @@ static int find_common(int fd[2], unsign
return retval;
}
+static int everything_local(struct ref *refs)
+{
+ int retval;
+
+ for (retval = 1; refs ; refs = refs->next) {
+ const unsigned char *remote = refs->old_sha1;
+ unsigned char local[20];
+
+ if (read_ref(git_path("%s", refs->name), local) < 0)
+ continue;
+
+ if (memcmp(remote, local, 20)) {
+ retval = 0;
+ if (!verbose)
+ continue;
+ fprintf(stderr,
+ "want %s (%s)\n", sha1_to_hex(remote),
+ refs->name);
+ continue;
+ }
+
+ memcpy(refs->new_sha1, local, 20);
+ if (!verbose)
+ continue;
+ fprintf(stderr,
+ "already have %s (%s)\n", sha1_to_hex(remote),
+ refs->name);
+ }
+ return retval;
+}
+
static int fetch_pack(int fd[2], int nr_match, char **match)
{
struct ref *ref;
@@ -86,6 +121,10 @@ static int fetch_pack(int fd[2], int nr_
packet_flush(fd[1]);
die("no matching remote head");
}
+ if (everything_local(ref)) {
+ packet_flush(fd[1]);
+ goto all_done;
+ }
if (find_common(fd, sha1, ref) < 0)
fprintf(stderr, "warning: no common commits\n");
pid = fork();
@@ -109,6 +148,7 @@ static int fetch_pack(int fd[2], int nr_
int code = WEXITSTATUS(status);
if (code)
die("git-unpack-objects died with error code %d", code);
+all_done:
while (ref) {
printf("%s %s\n",
sha1_to_hex(ref->old_sha1), ref->name);
^ permalink raw reply related
* Re: gitweb.cgi
From: H. Peter Anvin @ 2005-10-18 17:24 UTC (permalink / raw)
To: Kay Sievers; +Cc: Git Mailing List
In-Reply-To: <20051018110725.GB6929@vrfy.org>
Kay Sievers wrote:
>
>>Most of the hits we get are either the
>>gitweb front page or the gitweb rss feeds, and it's eating I/O bandwidth
>>like crazy.
>
> I tested some stuff on these boxes and 30 stat() calls alone take app. 2 seconds
> on these boxes cause of I/O load ... :)
>
Welcome to my hell :)
I set up mod_cache (which I didn't know about, silly me) and so far it
seems to work and has produced a tremendous decrease in load and
improvement in response time. I do, have, however, a request. There
are some gitweb pages which are more likely to change than others; in
particular, some gitweb pages will *never* change (because they directly
reflect immutable git data.)
If gitweb could produce Last-Modified and Expires headers where
appropriate, it should improve caching performance.
-hpa
^ permalink raw reply
* Re: gitweb.cgi
From: H. Peter Anvin @ 2005-10-18 16:52 UTC (permalink / raw)
To: Kay Sievers; +Cc: Git Mailing List
In-Reply-To: <20051018110725.GB6929@vrfy.org>
Kay Sievers wrote:
>
>>This has become particularly painful during the current one-server outage.
>>
>>Kay, gitweb really needs to be able to do caching, or be run behind a
>>caching proxy. Otherwise I will have to turn it off until we can come
>>up with a dedicated piece of server hardware for it.
>
> How about Apache's mod_cache? Worked nicely for me several times in other
> setups.
>
I will look at it and see if I can make it work properly.
-hpa
^ permalink raw reply
* 4aaa702794447d9b281dd22fe532fd61e02434e1
From: Morten Welinder @ 2005-10-18 15:04 UTC (permalink / raw)
To: GIT Mailing List
My "git pull" has turned unhappy within the past few days. Ideas?
Morten
$ git pull
Fetching refs/heads/master from
http://www.kernel.org/pub/scm/git/git.git/ using http
Getting alternates list
error: The requested URL returned error: 404 (curl_result = 22,
http_code = 404, sha1 = 4aaa702794447d9b281dd22fe532fd61e02434e1)
Getting pack list
error: Unable to find 4aaa702794447d9b281dd22fe532fd61e02434e1 under
http://www.kernel.org/pub/scm/git/git.git//
Cannot obtain needed object 4aaa702794447d9b281dd22fe532fd61e02434e1
while processing commit 0000000000000000000000000000000000000000.
^ permalink raw reply
* [PATCH] Fix cvsimport warning when called without --no-cvs-direct
From: Johannes Schindelin @ 2005-10-18 14:30 UTC (permalink / raw)
To: git, junkio
Perl was warning that $opt_p was undefined in that case.
Signed-off-by: Johannes Schindelin <Johannes.Schindelin@gmx.de>
---
git-cvsimport.perl | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
applies-to: ba55da41e2670b8728cf911ac7424bc1afeb6ce4
8d4a03322860fcc79cd20b76cb91b2f549cf14fd
diff --git a/git-cvsimport.perl b/git-cvsimport.perl
index 0621dc3..bbb83fb 100755
--- a/git-cvsimport.perl
+++ b/git-cvsimport.perl
@@ -487,7 +487,7 @@ unless($pid) {
my @opt;
@opt = split(/,/,$opt_p) if defined $opt_p;
unshift @opt, '-z', $opt_z if defined $opt_z;
- unless ($opt_p =~ m/--no-cvs-direct/) {
+ unless (defined($opt_p) && $opt_p =~ m/--no-cvs-direct/) {
push @opt, '--cvs-direct';
}
exec("cvsps",@opt,"-u","-A",'--root',$opt_d,$cvs_tree);
---
0.99.8.GIT
^ permalink raw reply related
* [PATCH] Ignore more generated files
From: Johannes Schindelin @ 2005-10-18 14:28 UTC (permalink / raw)
To: git, junkio
Since git-status now shows the "other" files, too, bring .gitignore
up-to-date.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
---
.gitignore | 3 +++
1 files changed, 3 insertions(+), 0 deletions(-)
applies-to: c96a7218cfb074d2847d54952c8570acd8bf08a9
555ff41f8df92ebb2cf58cb9797e339175733ef7
diff --git a/.gitignore b/.gitignore
index b34a77a..975e773 100644
--- a/.gitignore
+++ b/.gitignore
@@ -86,6 +86,7 @@ git-ssh-push
git-ssh-upload
git-status
git-stripspace
+git-svnimport
git-symbolic-ref
git-tag
git-tar-tree
@@ -106,3 +107,5 @@ git-core-*/?*
*.deb
git-core.spec
*.exe
+libgit.a
+*.o
---
0.99.8.GIT
^ permalink raw reply related
* [PATCH] No funny names on cygwin...
From: Johannes Schindelin @ 2005-10-18 14:27 UTC (permalink / raw)
To: git, junkio
On FAT/NTFS, filenames cannot contain tabs. So t3300-funny-names would
reliably fail already when trying to create such files.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
---
t/t3300-funny-names.sh | 3 +++
1 files changed, 3 insertions(+), 0 deletions(-)
applies-to: 2a40773d42d149766148a0c4ed9c501b67d55ee4
b92942c59ac2c70d867035e8ed4f6eca1f53df1b
diff --git a/t/t3300-funny-names.sh b/t/t3300-funny-names.sh
index ccd7063..897c378 100755
--- a/t/t3300-funny-names.sh
+++ b/t/t3300-funny-names.sh
@@ -9,6 +9,9 @@ This test tries pathnames with funny cha
tree, index, and tree objects.
'
+# since FAT/NTFS does not allow tabs in filenames, skip this test
+test "$(uname -o 2>/dev/null)" = Cygwin && exit 0
+
. ./test-lib.sh
p0='no-funny'
---
0.99.8.GIT
^ permalink raw reply related
* Re: gitweb.cgi
From: Kay Sievers @ 2005-10-18 11:07 UTC (permalink / raw)
To: H. Peter Anvin; +Cc: Git Mailing List
In-Reply-To: <43546492.3020401@zytor.com>
On Mon, Oct 17, 2005 at 07:57:22PM -0700, H. Peter Anvin wrote:
> It is increasingly clear that gitweb.cgi is producing an unacceptable
> load on the kernel.org servers.
Sure, sorry, was on 3 conferences in a row the last weeks.
> Most of the hits we get are either the
> gitweb front page or the gitweb rss feeds, and it's eating I/O bandwidth
> like crazy.
I tested some stuff on these boxes and 30 stat() calls alone take app. 2 seconds
on these boxes cause of I/O load ... :)
> This has become particularly painful during the current one-server outage.
>
> Kay, gitweb really needs to be able to do caching, or be run behind a
> caching proxy. Otherwise I will have to turn it off until we can come
> up with a dedicated piece of server hardware for it.
How about Apache's mod_cache? Worked nicely for me several times in other
setups.
Kay
^ permalink raw reply
* [PATCH] git-checkout: revert specific paths to either index or a given tree-ish.
From: Junio C Hamano @ 2005-10-18 8:34 UTC (permalink / raw)
To: git; +Cc: Linus Torvalds
In-Reply-To: <7vmzl7tv89.fsf@assigned-by-dhcp.cox.net>
When extra paths arguments are given, git-checkout reverts only those
paths to either the version recorded in the index or the version
recorded in the given tree-ish.
This has been on the TODO list for quite a while.
Signed-off-by: Junio C Hamano <junkio@cox.net>
---
Junio C Hamano <junkio@cox.net> writes:
> Linus Torvalds <torvalds@osdl.org> writes:
>
>> Btw, I'd really like a "git checkout" that can do the per-file thing,
>> instead of always using the equivalent of git-checkout-index with "-a".
>>
>> and I suspect that a lot of people would prefer that
>>
>> git checkout filename
>>
>> would just do that. Instead, we error out ("no such branch"). Which
>> isn't even what I want, and almost certainly not what most CVS users want
>> (they're used to checking out individual files).
I've redone this a bit differently since last night's "in
the meantime..." patch, so that we can pull selected paths
out of arbitrary tree-ish.
git-checkout.sh | 79 ++++++++++++++++++++++++++++++++--------
Documentation/git-checkout.txt | 42 ++++++++++++++++++++-
2 files changed, 103 insertions(+), 18 deletions(-)
applies-to: f7e1a8387657c4da9991861ae44347813b67bc46
4aaa702794447d9b281dd22fe532fd61e02434e1
diff --git a/Documentation/git-checkout.txt b/Documentation/git-checkout.txt
index f753c14..b7bb1b4 100644
--- a/Documentation/git-checkout.txt
+++ b/Documentation/git-checkout.txt
@@ -7,12 +7,24 @@ git-checkout - Checkout and switch to a
SYNOPSIS
--------
-'git-checkout' [-f] [-b <new_branch>] [<branch>]
+'git-checkout' [-f] [-b <new_branch>] [<branch>] [<paths>...]
DESCRIPTION
-----------
-Updates the index and working tree to reflect the specified branch,
-<branch>. Updates HEAD to be <branch> or, if specified, <new_branch>.
+
+When <paths> are not given, this command switches branches, by
+updating the index and working tree to reflect the specified
+branch, <branch>, and updating HEAD to be <branch> or, if
+specified, <new_branch>.
+
+When <paths> are given, this command does *not* switch
+branches. It updates the named paths in the working tree from
+the index file (i.e. it runs `git-checkout-index -f -u`). In
+this case, `-f` and `-b` options are meaningless and giving
+either of them results in an error. <branch> argument can be
+used to specify a specific tree-ish to update the index for the
+given paths before updating the working tree.
+
OPTIONS
-------
@@ -29,6 +41,30 @@ OPTIONS
Branch to checkout; may be any object ID that resolves to a
commit. Defaults to HEAD.
+
+EXAMPLE
+-------
+
+The following sequence checks out the `master` branch, reverts
+the `Makefile` to two revisions back, deletes hello.c by
+mistake, and gets it back from the index.
+
+------------
+$ git checkout master
+$ git checkout master~2 Makefile
+$ rm -f hello.c
+$ git checkout hello.c
+------------
+
+If you have an unfortunate branch that is named `hello.c`, the
+last step above would be confused as an instruction to switch to
+that branch. You should instead write:
+
+------------
+$ git checkout -- hello.c
+------------
+
+
Author
------
Written by Linus Torvalds <torvalds@osdl.org>
diff --git a/git-checkout.sh b/git-checkout.sh
index 2c053a3..73652fa 100755
--- a/git-checkout.sh
+++ b/git-checkout.sh
@@ -23,32 +23,81 @@ while [ "$#" != "0" ]; do
"-f")
force=1
;;
+ --)
+ break
+ ;;
*)
- rev=$(git-rev-parse --verify "$arg^0" 2>/dev/null) ||
- die "I don't know any '$arg'."
- if [ -z "$rev" ]; then
- echo "unknown flag $arg"
- exit 1
- fi
- if [ "$new" ]; then
- echo "Multiple revisions?"
- exit 1
- fi
- new="$rev"
- if [ -f "$GIT_DIR/refs/heads/$arg" ]; then
- branch="$arg"
+ if rev=$(git-rev-parse --verify "$arg^0" 2>/dev/null)
+ then
+ if [ -z "$rev" ]; then
+ echo "unknown flag $arg"
+ exit 1
+ fi
+ new="$rev"
+ if [ -f "$GIT_DIR/refs/heads/$arg" ]; then
+ branch="$arg"
+ fi
+ elif rev=$(git-rev-parse --verify "$arg^{tree}" 2>/dev/null)
+ then
+ # checking out selected paths from a tree-ish.
+ new="$rev"
+ branch=
+ else
+ new=
+ branch=
+ set x "$arg" "$@"
+ shift
fi
+ break
;;
esac
done
-[ -z "$new" ] && new=$old
+# The behaviour of the command with and without explicit path
+# parameters is quite different.
+#
+# Without paths, we are checking out everything in the work tree,
+# possibly switching branches. This is the traditional behaviour.
#
+# With paths, we are _never_ switching branch, but checking out
+# the named paths from either index (when no rev is given),
+# or the named tree-ish (when rev is given).
+
+if test "$#" -ge 1
+then
+ if test '' != "$newbranch$force"
+ then
+ die "updating paths and switching branches or forcing are incompatible."
+ fi
+ if test '' != "$new"
+ then
+ # from a specific tree-ish; note that this is for
+ # rescuing paths and is never meant to remove what
+ # is not in the named tree-ish.
+ git-ls-tree -r "$new" "$@" |
+ sed -ne 's/^\([0-7]*\) blob \(.*\)$/\1 \2/p' |
+ git-update-index --index-info || exit $?
+ fi
+ git-checkout-index -f -u -- "$@"
+ exit $?
+else
+ # Make sure we did not fall back on $arg^{tree} codepath
+ # since we are not checking out from an arbitrary tree-ish,
+ # but switching branches.
+ if test '' != "$new"
+ then
+ git-rev-parse --verify "$new^{commit}" >/dev/null 2>&1 ||
+ die "Cannot switch branch to a non-commit."
+ fi
+fi
+
+[ -z "$new" ] && new=$old
+
# If we don't have an old branch that we're switching to,
# and we don't have a new branch name for the target we
# are switching to, then we'd better just be checking out
# what we already had
-#
+
[ -z "$branch$newbranch" ] &&
[ "$new" != "$old" ] &&
die "git checkout: you need to specify a new branch name"
---
0.99.8.GIT
^ permalink raw reply related
* Handle "-" at beginning of filenames, part 3
From: Linus Torvalds @ 2005-10-18 5:57 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <Pine.LNX.4.64.0510172243560.3369@g5.osdl.org>
This fixes the default built-in exec() of "diff" to add a "--" before the
filenames, so that if a filename starts with a "-", the diff program won't
think it's an option.
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
---
This should complete the series. Now all the parts should be safe and pass
on "--" properly. Knock wood.
On Mon, 17 Oct 2005, Linus Torvalds wrote:
>
> It adds "--" to the git-diff.sh scripts, to keep any filenames that start
> with a "-" from being confused with an option.
diff --git a/diff.c b/diff.c
index cbb8632..d6b5086 100644
--- a/diff.c
+++ b/diff.c
@@ -134,7 +134,7 @@ static void builtin_diff(const char *nam
{
int i, next_at, cmd_size;
const char *const diff_cmd = "diff -L%s%s -L%s%s";
- const char *const diff_arg = "%s %s||:"; /* "||:" is to return 0 */
+ const char *const diff_arg = "-- %s %s||:"; /* "||:" is to return 0 */
const char *input_name_sq[2];
const char *path0[2];
const char *path1[2];
^ permalink raw reply related
* GIT 0.99.8e
From: Junio C Hamano @ 2005-10-18 5:53 UTC (permalink / raw)
To: git; +Cc: linux-kernel
In-Reply-To: <7vachadnmy.fsf@assigned-by-dhcp.cox.net>
GIT 0.99.8e is available as usual at:
RPMs and tarball: www.kernel.org:/pub/software/scm/git/
Debs and tarball: www.kernel.org:/pub/software/scm/git/debian/
The "master" branch has updated "git-diff-*" commands, that deal
with pathnames with funny characters (most importantly tabs and
newlines) in a way compatible with the proposed change to GNU
patch, which was outlined in:
http://marc.theaimsgroup.com/?l=git&m=112927316408690&w=2
When people start generating diffs with them, patches that touch
paths that have double-quotes '"' or spaces ' ' in them need to
be applied with the updated git-apply that knows how new
"git-diff-*" encodes these funny pathnames. GIT 0.99.8e
contains the necessary backport of the git-apply changes.
This will hopefully be the last 0.99.8 maintenance release.
^ permalink raw reply
* Teach "git diff" to handle filenames startign with '-'
From: Linus Torvalds @ 2005-10-18 5:49 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <Pine.LNX.4.64.0510171933200.3369@g5.osdl.org>
It adds "--" to the git-diff.sh scripts, to keep any filenames that start
with a "-" from being confused with an option.
But in order to do that, it needs to teach git-diff-files to honor "--".
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
---
On Mon, 17 Oct 2005, Linus Torvalds wrote:
>
> Yes, I know it's ambigious at times, but it really is very convenient.
> Usually we allow a "--" to say where a filename starts when it _is_
> ambiguous.
This is on top of the rev-parse.c diff (it's strictly independent, but it
needs the rev-parse.c one to make any sense, since without the rev-parse.c
fix for -- handling, "git diff" won't work regardless).
diff --git a/diff-files.c b/diff-files.c
index 8a8f9b6..1789939 100644
--- a/diff-files.c
+++ b/diff-files.c
@@ -41,6 +41,11 @@ int main(int argc, const char **argv)
git_config(git_default_config);
diff_setup(&diff_options);
while (1 < argc && argv[1][0] == '-') {
+ if (!strcmp(argv[1], "--")) {
+ argv++;
+ argc--;
+ break;
+ }
if (!strcmp(argv[1], "-q"))
silent = 1;
else if (!strcmp(argv[1], "-r"))
diff --git a/git-diff.sh b/git-diff.sh
index 84a152a..b3ec84b 100755
--- a/git-diff.sh
+++ b/git-diff.sh
@@ -28,16 +28,16 @@ case "$rev" in
?*' '^?*)
begin=$(expr "$rev" : '.*^.\([0-9a-f]*\).*') &&
end=$(expr "$rev" : '.\([0-9a-f]*\). .*') || exit
- cmd="git-diff-tree $flags $begin $end $files"
+ cmd="git-diff-tree $flags $begin $end -- $files"
;;
?*' '?*)
- cmd="git-diff-tree $flags $rev $files"
+ cmd="git-diff-tree $flags $rev -- $files"
;;
?*' ')
- cmd="git-diff-index $flags $rev $files"
+ cmd="git-diff-index $flags $rev -- $files"
;;
'')
- cmd="git-diff-files $flags $files"
+ cmd="git-diff-files $flags -- $files"
;;
*)
die "I don't understand $*"
^ permalink raw reply related
* Re: Scribblings for a cogito/git tutorial
From: Horst von Brand @ 2005-10-18 3:12 UTC (permalink / raw)
To: David Whistler; +Cc: git
In-Reply-To: <loom.20051018T042052-760@post.gmane.org>
David Whistler <dwhistler@gmail.com> wrote:
> Horst von Brand <vonbrand <at> inf.utfsm.cl> writes:
[...]
> > Comments, suggestions, patches are welcome!
> >
> > Repository of the script and supporting files is at
> > <http://pincoya.inf.utfsm.cl/Script.git>
> I can't read it. Seems to be a recursive trick.
Latest cogito + latest git here clones it without problems over the 'net
(from home, via ADSL).
> Or did you mean to do that?
I might have set it up wrong, but it doesn't look that way.
--
Dr. Horst H. von Brand User #22616 counter.li.org
Departamento de Informatica Fono: +56 32 654431
Universidad Tecnica Federico Santa Maria +56 32 654239
Casilla 110-V, Valparaiso, Chile Fax: +56 32 797513
^ permalink raw reply
* gitweb.cgi
From: H. Peter Anvin @ 2005-10-18 2:57 UTC (permalink / raw)
To: Kay Sievers, Git Mailing List
It is increasingly clear that gitweb.cgi is producing an unacceptable
load on the kernel.org servers. Most of the hits we get are either the
gitweb front page or the gitweb rss feeds, and it's eating I/O bandwidth
like crazy.
This has become particularly painful during the current one-server outage.
Kay, gitweb really needs to be able to do caching, or be run behind a
caching proxy. Otherwise I will have to turn it off until we can come
up with a dedicated piece of server hardware for it.
-hpa
^ permalink raw reply
* Re: git-checkout-index, flag ordering and --prefix kludgy handling
From: Linus Torvalds @ 2005-10-18 2:48 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vmzl7tv89.fsf@assigned-by-dhcp.cox.net>
On Mon, 17 Oct 2005, Junio C Hamano wrote:
>
> One reason I have not done nor said much about this was because
> I've been thinking about making the branch/refname more explicit
> on our command line.
Yes, I know it's ambigious at times, but it really is very convenient.
Usually we allow a "--" to say where a filename starts when it _is_
ambiguous.
However, you're right, we fail that at times. In particular, git-rev-parse
fails it.
Something like this?
Linus
---
diff --git a/rev-parse.c b/rev-parse.c
index 41b9dae..85230df 100644
--- a/rev-parse.c
+++ b/rev-parse.c
@@ -151,6 +151,12 @@ static void show_datestring(const char *
show(buffer);
}
+static void show_file(const char *arg)
+{
+ if ((filter & (DO_NONFLAGS|DO_NOREV)) == (DO_NONFLAGS|DO_NOREV))
+ show(arg);
+}
+
int main(int argc, char **argv)
{
int i, as_is = 0, verify = 0;
@@ -162,7 +168,7 @@ int main(int argc, char **argv)
char *dotdot;
if (as_is) {
- show(arg);
+ show_file(arg);
continue;
}
if (*arg == '-') {
@@ -282,9 +288,7 @@ int main(int argc, char **argv)
}
if (verify)
die("Needed a single revision");
- if ((filter & (DO_NONFLAGS|DO_NOREV)) ==
- (DO_NONFLAGS|DO_NOREV))
- show(arg);
+ show_file(arg);
}
show_default();
if (verify && revs_count != 1)
^ permalink raw reply related
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