* Re: maybe breakage with latest git-pull and http protocol
From: Nick Hengeveld @ 2005-10-20 17:43 UTC (permalink / raw)
To: Randal L. Schwartz; +Cc: git
In-Reply-To: <867jciz18w.fsf@blue.stonehenge.com>
Can you try using the following patch? This cleans up curl handles for
active request slots that are no longer in use. If all other prefetched
requests finish while a large transfer is happening, the active slots
currently keep open connections to the server and I'm guessing that
perhaps by the time additional objects are prefetched the server has
timed out some of those keepalive connections.
---
http-fetch.c | 26 ++++++++++++++++++++------
1 files changed, 20 insertions(+), 6 deletions(-)
applies-to: ce9a5a0fdd52a29e370d849a132b4509c844aca1
04b4353279eaceb7e7c3d73a9565b219aa7a10a9
diff --git a/http-fetch.c b/http-fetch.c
index a7dc2cc..d26fae8 100644
--- a/http-fetch.c
+++ b/http-fetch.c
@@ -291,11 +291,7 @@ static struct active_request_slot *get_a
}
if (slot == NULL) {
newslot = xmalloc(sizeof(*newslot));
-#ifdef NO_CURL_EASY_DUPHANDLE
- newslot->curl = get_curl_handle();
-#else
- newslot->curl = curl_easy_duphandle(curl_default);
-#endif
+ newslot->curl = NULL;
newslot->in_use = 0;
newslot->next = NULL;
@@ -311,6 +307,14 @@ static struct active_request_slot *get_a
slot = newslot;
}
+ if (slot->curl == NULL) {
+#ifdef NO_CURL_EASY_DUPHANDLE
+ slot->curl = get_curl_handle();
+#else
+ slot->curl = curl_easy_duphandle(curl_default);
+#endif
+ }
+
active_requests++;
slot->in_use = 1;
slot->done = 0;
@@ -612,6 +616,7 @@ void process_curl_messages(void)
void process_request_queue(void)
{
struct transfer_request *request = request_queue_head;
+ struct active_request_slot *slot = active_queue_head;
int num_transfers;
while (active_requests < max_requests && request != NULL) {
@@ -624,6 +629,14 @@ void process_request_queue(void)
}
request = request->next;
}
+
+ while (slot != NULL) {
+ if (!slot->in_use && slot->curl != NULL) {
+ curl_easy_cleanup(slot->curl);
+ slot->curl = NULL;
+ }
+ slot = slot->next;
+ }
}
#endif
@@ -1297,7 +1310,8 @@ int main(int argc, char **argv)
#endif
slot = active_queue_head;
while (slot != NULL) {
- curl_easy_cleanup(slot->curl);
+ if (slot->curl != NULL)
+ curl_easy_cleanup(slot->curl);
slot = slot->next;
}
#ifdef USE_CURL_MULTI
---
0.99.8.GIT
--
For a successful technology, reality must take precedence over public
relations, for nature cannot be fooled.
^ permalink raw reply related
* [PATCH] [PATCH] add commitdiff option in history window
From: Paolo 'Blaisorblade' Giarrusso @ 2005-10-20 17:28 UTC (permalink / raw)
To: Kay Sievers; +Cc: git
In the history window I like to have the commitdiff link too. Hope this
patch is correct. Thanks for review.
Signed-off-by: Paolo 'Blaisorblade' Giarrusso <blaisorblade@yahoo.it>
---
gitweb.cgi | 1 +
1 files changed, 1 insertions(+), 0 deletions(-)
diff --git a/gitweb.cgi b/gitweb.cgi
--- a/gitweb.cgi
+++ b/gitweb.cgi
@@ -2028,6 +2028,7 @@ sub git_history {
escapeHTML(chop_str($co{'title'}, 50)) . "</b>") . "</td>\n" .
"<td class=\"link\">" .
$cgi->a({-href => "$my_uri?p=$project;a=commit;h=$commit"}, "commit") .
+ " | " . $cgi->a({-href => "$my_uri?p=$project;a=commitdiff;h=$commit"}, "commitdiff") .
" | " . $cgi->a({-href => "$my_uri?p=$project;a=blob;hb=$commit;f=$file_name"}, "blob");
my $blob = git_get_hash_by_path($hash, $file_name);
my $blob_parent = git_get_hash_by_path($commit, $file_name);
^ permalink raw reply
* Re: Revamping the git protocol
From: Linus Torvalds @ 2005-10-20 17:17 UTC (permalink / raw)
To: H. Peter Anvin; +Cc: Petr Baudis, Junio C Hamano, git
In-Reply-To: <4357CB57.3070802@zytor.com>
On Thu, 20 Oct 2005, H. Peter Anvin wrote:
>
> git over ssh seems to be the obvious choice.
Yes, but Petr is right that there might be room for some lighter-weight
"gits" secure protocol. One that doesn't necessarily require a whole user
ID thing.
For example, let's say that you're not the maintainer of your machine, but
you're in an environment where you are allowed to run daemons as yourself
(at a university, for example). And you have a group of people who want to
work together at a project, but they don't want to give write permissions
to the world or their bigger group (group "student").
And git itself _does_ actually support that, already. You can use the
standard "ssh:" thing (or just "hostname:pathname"), and the GIT_SSH
environment variable to set up any tunnelling program you want. Then you
can authenticate any way you want (and encrypt or not, whatever)..
So if somebody is in this situation, maybe we could have an example tunnel
client/server thing that does this.
This is unrelated to the git protocol itself, although the "pack over
ssh/tunnel" obviously uses all the same stuff for the actual transfer.
(It might also be worthwhile to have .git/config specify what program to
use, so that you don't need a global environment variable. It might even
be per-host, ie we could have git-send-pack and git-fetch-pack understand
config language like
[connect]
program=[server.uni.edu]:mytunnel
or something. It shouldn't even be hard to do. Certainly simpler than
doing a good authenticating tunnel).
Linus
^ permalink raw reply
* Re: Revamping the git protocol
From: H. Peter Anvin @ 2005-10-20 16:52 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Petr Baudis, Junio C Hamano, git
In-Reply-To: <Pine.LNX.4.64.0510200924110.3369@g5.osdl.org>
Linus Torvalds wrote:
>
> Similarly, git-upload-pack can be future-proofed by having it have some
> data transfer timeout: if it doesn't make any progress at all in <n>
> seconds, just kill itself. Things like _that_ are likely to be a lot more
> important, I suspect.
>
Right, I already submitted a patch for that.
> And no, I don't think th egit protocol should do authentication. It's
> hard. If you want to do authentication, you need to do encryption too, and
> then you should do something else (but the git protocol _does_ work fine
> over an encyrpted channel, so the "something else" might be to have some
> secure web interface tunnel protocol or similar, and then just support
> "git over https" or something ;).
git over ssh seems to be the obvious choice.
-hpa
^ permalink raw reply
* Re: Revamping the git protocol
From: Linus Torvalds @ 2005-10-20 16:38 UTC (permalink / raw)
To: Petr Baudis; +Cc: Junio C Hamano, H. Peter Anvin, git
In-Reply-To: <20051020091245.GY30889@pasky.or.cz>
On Thu, 20 Oct 2005, Petr Baudis wrote:
>
> What's wrong with my scheme? That is, _reply_ with challenge to the
> upload-pack command.
Neither your not Peter's scheme seems to be at all worried about backwards
compatibility, and I just don't see _why_.
Even if you can upgrade all servers (there aren't that many of them), why
force a client upgrade when the protocol is designed to be extensible?
Especially for somethign that doesn't even _buy_ you anything right now.
In fact, I'm not even sure it buys you anything in the future. The thing
is, SYN-flooding depends on overwhelming you with lots of simple packets.
And since in the git protocol, the expense is not in the _packets_ but in
the server-side packing and data transfer, I don't see the point.
If you want to DoS a git pack server, you open a hundred _real_ git
connections to it, carefully selected so that they get unique packs (so
that the server can't cache them). You don't need to have some distributed
denial-of-service attack with lots of magic packets.
This is why the git daemon already limits the clients to 25 by default or
something like that - it doesn't want to put too much strain on the
server.
A much more important thing the git daemon could do is to kill connections
from the same IP address when there's more than 25 pending ones. The
daemon actualy has the infrastructure for that - it's why it doesn't just
count its children, it actually saves child information away (it just
doesn't _use_ it for anything right now).
Similarly, git-upload-pack can be future-proofed by having it have some
data transfer timeout: if it doesn't make any progress at all in <n>
seconds, just kill itself. Things like _that_ are likely to be a lot more
important, I suspect.
And no, I don't think th egit protocol should do authentication. It's
hard. If you want to do authentication, you need to do encryption too, and
then you should do something else (but the git protocol _does_ work fine
over an encyrpted channel, so the "something else" might be to have some
secure web interface tunnel protocol or similar, and then just support
"git over https" or something ;).
Linus
^ permalink raw reply
* Re: Revamping the git protocol
From: Linus Torvalds @ 2005-10-20 16:20 UTC (permalink / raw)
To: H. Peter Anvin; +Cc: Git Mailing List
In-Reply-To: <43571DA1.6030907@zytor.com>
On Wed, 19 Oct 2005, H. Peter Anvin wrote:
>
> 1. "Strings" are sequences of bytes prefixed with a length. The length is
> encoded as four lower-case hexadecimal digits. [Why not as 2 or 4 bytes of
> network byte order binary?] When represented in this text as "foo", this
> means the sequence of bytes on the wire is <0003foo>.
As a reason for your "why" - imagine debugging a protocol using telnet..
ASCII really is very nice for things like that.
And no, "foo" is not represented as <0003foo>. It's represented as
<0007foo>, because the length includes the length of the prefix.
The special sequence <0000> is a flush sequence, and it's designed so that
it's supposed to be distinguishable from an empty string <0004>. A <0001>
to <0003> will be rejected as an error. Maximum string length is thus
65531.
(Actually, right now flush it is _not_ distinguishable from an empty
string because we return 0 for both cases from packet_read_line(), but the
point being that the packet protocol _supports_ it being distinguishable
if we ever need it to).
Linus
^ permalink raw reply
* Re: Revamping the git protocol
From: H. Peter Anvin @ 2005-10-20 15:50 UTC (permalink / raw)
To: Petr Baudis; +Cc: Junio C Hamano, git
In-Reply-To: <20051020091245.GY30889@pasky.or.cz>
Petr Baudis wrote:
> Dear diary, on Thu, Oct 20, 2005 at 08:11:17AM CEST, I got a letter
> where Junio C Hamano <junkio@cox.net> told me that...
>
>>I am wondering if we can just get away with a simpler scheme
>>Linus outlined instead. One drawback of that approach is it
>>does not easily allow things like challenge-response uniformly
>>across different commands (admittedly we only have "upload-pack"
>>command right now, but we could add list of supported commands
>>easily in execute()), but you could do something along this, I
>>presume?
>
> What's wrong with my scheme? That is, _reply_ with challenge to the
> upload-pack command. This should be equally powerful to the Linus'
> scheme and the crucial advantage is that you do not need to tell at
> the client side whether you are talking to a new server or an old one.
>
> I was convinced that the authentication part of the challenge-resposne
> isn't such a good idea after all, though. ;-)
>
Anyone noticed that either of those schemes aren't actually
backward-compatible in any way (old client talking to new server will be
disconnected), and that unfortunately is the best thing one can do with
the current setup, exactly because there is no option negotiation phase?
Another issue is that currently there is no error information propagated
back to the client; the server logs an error in its own logs, but the
client is simply disconnected.
-hpa
^ permalink raw reply
* [PATCH] Make git-cherry-pick in target "all"
From: Johannes Schindelin @ 2005-10-20 15:13 UTC (permalink / raw)
To: git, junkio
Since git-cherry-pick is simply a copy of git-revert, it can be created
before installing (so that it can be used without installing, too).
Signed-off-by: Johannes Schindelin <Johannes.Schindelin@gmx.de>
---
.gitignore | 1 +
Makefile | 6 ++++--
2 files changed, 5 insertions(+), 2 deletions(-)
applies-to: 4380edd21387645ec027e365df316e93820cfc13
35408716ef9d85bc2feaf71c3d6cf20345c7f635
diff --git a/.gitignore b/.gitignore
index 975e773..52cb9e2 100644
--- a/.gitignore
+++ b/.gitignore
@@ -12,6 +12,7 @@ git-check-ref-format
git-checkout
git-checkout-index
git-cherry
+git-cherry-pick
git-clone
git-clone-pack
git-commit
diff --git a/Makefile b/Makefile
index 5fa9f4f..b043175 100644
--- a/Makefile
+++ b/Makefile
@@ -314,7 +314,7 @@ DEFINES += -DSHA1_HEADER=$(call shellquo
SCRIPTS = $(patsubst %.sh,%,$(SCRIPT_SH)) \
$(patsubst %.perl,%,$(SCRIPT_PERL)) \
$(patsubst %.py,%,$(SCRIPT_PYTHON)) \
- gitk
+ gitk git-cherry-pick
export prefix TAR INSTALL DESTDIR SHELL_PATH template_dir
### Build rules
@@ -355,6 +355,9 @@ $(patsubst %.py,%,$(SCRIPT_PYTHON)) : %
$@.py >$@
chmod +x $@
+git-cherry-pick: git-revert
+ cp $< $@
+
%.o: %.c
$(CC) -o $*.o -c $(ALL_CFLAGS) $<
%.o: %.S
@@ -414,7 +417,6 @@ check:
install: $(PROGRAMS) $(SCRIPTS)
$(INSTALL) -d -m755 $(call shellquote,$(DESTDIR)$(bindir))
$(INSTALL) $(PROGRAMS) $(SCRIPTS) $(call shellquote,$(DESTDIR)$(bindir))
- $(INSTALL) git-revert $(call shellquote,$(DESTDIR)$(bindir)/git-cherry-pick)
sh ./cmd-rename.sh $(call shellquote,$(DESTDIR)$(bindir))
$(MAKE) -C templates install
$(INSTALL) -d -m755 $(call shellquote,$(DESTDIR)$(GIT_PYTHON_DIR))
---
0.99.8.GIT
^ permalink raw reply related
* [PATCH] Do not use git-rev-list in git-fetch-pack
From: Johannes Schindelin @ 2005-10-20 15:12 UTC (permalink / raw)
To: git, junkio
The code used to call git-rev-list to enumerate the local revisions.
A disadvantage of that method was that git-fetch-pack would happily
enumerate ancestors of acknowledged common commits, which was just
taking unnecessary bandwidth.
Further, git-upload-pack makes use only of the first MAX_HAS == 16
revisions! So if git-fetch-pack has something to say, it better does
so concisely.
Therefore, do not use git-rev-list on the fetching side. Send the
revisions starting with the local heads, ignoring the acknowledged
revisions and their ancestors.
When git-fetch-pack is verbose, it now says which sha1 got acknowledged.
Signed-off-by: Johannes Schindelin <Johannes.Schindelin@gmx.de>
---
I am quite certain that MAX_HAS is too low. Since
MAX_NEEDS == 256, I think this value would be better for
MAX_HAS, too, especially since git-fetch-pack no longer
sends so much crud with this patch.
Also: If I read the code correctly, find_common() only sends
"have" lines as long as it does not receive an "ACK" line,
i.e. in effect git-fetch-pack sends only up to the first
common revision (plus at most 31 others).
That is all well if we are expecting only one upstream
repository, but not in a truly distributed environment.
Maybe it is time to revise that behaviour? For example,
fetch-pack could stop when it is out of non-common revs,
or when it got MAX_HAS "ACK" lines.
Also, git-upload-pack could accept only up to a certain
number of "have" lines.
fetch-pack.c | 143 ++++++++++++++++++++++++++++++++++++++++++++--------------
1 files changed, 109 insertions(+), 34 deletions(-)
applies-to: 50f9bed9a78e1f51178ebf6be3cd9c20b2ffcb0b
2b5886e2198ea4b8403839b7188e8ad9e6f1713b
diff --git a/fetch-pack.c b/fetch-pack.c
index 8566ab1..cdde008 100644
--- a/fetch-pack.c
+++ b/fetch-pack.c
@@ -13,18 +13,110 @@ static const char fetch_pack_usage[] =
static const char *exec = "git-upload-pack";
#define COMPLETE (1U << 0)
+#define COMMON (1U << 1)
+#define COMMON_REF (1U << 2)
+#define TO_SCAN (1U << 3)
+
+struct commit_list *rev_list = NULL;
+
+/*
+ Unfortunately, we want not only commits, but sometimes also tags.
+*/
+
+static struct commit *fake_commit(struct object *object) {
+ struct commit *ret;
+
+ if (object->type == commit_type)
+ return (struct commit *)object;
+
+ ret = xmalloc(sizeof(struct commit));
+
+ memset(ret, 0, sizeof(struct commit));
+ ret->object = *object;
+
+ /* insert_by_date() shall put it at the end */
+ ret->date = 0;
+
+ return ret;
+}
+
+static int rev_list_insert(const char *path, const unsigned char *sha1)
+{
+ struct commit *commit = fake_commit(parse_object(sha1));
+
+ /*
+ Local heads are much more likely to be common, so send them first.
+ */
+ if (commit->object.type == commit_type)
+ commit_list_insert(commit, &rev_list);
+ else {
+ insert_by_date(commit, &rev_list);
+
+ if (commit->object.type == tag_type) {
+ /* This commit has been faked. Reget. */
+ struct object *o = lookup_object(commit->object.sha1);
+ o = deref_tag(o);
+ if (o->type == commit_type)
+ insert_by_date((struct commit *)o, &rev_list);
+ }
+ }
+
+ return 0;
+}
+
+/*
+ Get the next rev to send, ignoring the common.
+*/
+
+static const unsigned char* get_rev()
+{
+ struct commit *commit = NULL;
+
+ while (commit == NULL) {
+ unsigned int mark;
+
+ if (rev_list == NULL)
+ return NULL;
+
+ commit = rev_list->item;
+
+ if (commit->object.flags&COMMON) {
+ /* do not send "have", and ignore ancestors */
+ commit = NULL;
+ mark = COMMON | TO_SCAN;
+ } else if (commit->object.flags&COMMON_REF)
+ /* send "have", and ignore ancestors */
+ mark = COMMON | TO_SCAN;
+ else
+ /* send "have", also for ancestors, until one is ack'ed */
+ mark = TO_SCAN;
+
+ pop_most_recent_commit(&rev_list, mark);
+ }
+
+ return commit->object.sha1;
+}
+
+static void mark_common(const unsigned char* sha1)
+{
+ struct object *o = lookup_object(sha1);
+
+ if (o != NULL && !(o->flags&COMMON)) {
+ o->flags |= COMMON;
+ if (o->type == commit_type)
+ insert_by_date((struct commit *)o, &rev_list);
+ }
+}
static int find_common(int fd[2], unsigned char *result_sha1,
struct ref *refs)
{
int fetching;
- static char line[1000];
- static char rev_command[1024];
- int count = 0, flushes = 0, retval, rev_command_len;
- FILE *revs;
+ int count = 0, flushes = 0, retval;
+ const unsigned char *sha1;
+
+ for_each_ref(rev_list_insert);
- strcpy(rev_command, "git-rev-list $(git-rev-parse --all)");
- rev_command_len = strlen(rev_command);
fetching = 0;
for ( ; refs ; refs = refs->next) {
unsigned char *remote = refs->old_sha1;
@@ -42,25 +134,11 @@ static int find_common(int fd[2], unsign
*/
if (((o = lookup_object(remote)) != NULL) &&
(o->flags & COMPLETE)) {
- struct commit_list *p;
- struct commit *commit =
- (struct commit *) (o = deref_tag(o));
- if (!o)
- goto repair;
- if (o->type != commit_type)
- continue;
- p = commit->parents;
- while (p &&
- rev_command_len + 44 < sizeof(rev_command)) {
- snprintf(rev_command + rev_command_len, 44,
- " ^%s",
- sha1_to_hex(p->item->object.sha1));
- rev_command_len += 43;
- p = p->next;
- }
+ o->flags |= COMMON_REF | TO_SCAN;
+ commit_list_insert(fake_commit(o), &rev_list);
continue;
}
- repair:
+
packet_write(fd[1], "want %s\n", sha1_to_hex(remote));
fetching++;
}
@@ -68,21 +146,16 @@ static int find_common(int fd[2], unsign
if (!fetching)
return 1;
- revs = popen(rev_command, "r");
- if (!revs)
- die("unable to run 'git-rev-list'");
-
flushes = 1;
retval = -1;
- while (fgets(line, sizeof(line), revs) != NULL) {
- unsigned char sha1[20];
- if (get_sha1_hex(line, sha1))
- die("git-fetch-pack: expected object name, got crud");
+ while ((sha1 = get_rev())) {
packet_write(fd[1], "have %s\n", sha1_to_hex(sha1));
if (verbose)
fprintf(stderr, "have %s\n", sha1_to_hex(sha1));
if (!(31 & ++count)) {
packet_flush(fd[1]);
+ if (verbose)
+ fprintf(stderr, "flush\n");
flushes++;
/*
@@ -92,16 +165,17 @@ static int find_common(int fd[2], unsign
if (count == 32)
continue;
if (get_ack(fd[0], result_sha1)) {
+ mark_common(result_sha1);
flushes = 0;
retval = 0;
if (verbose)
- fprintf(stderr, "got ack\n");
+ fprintf(stderr, "got ack %s\n",
+ sha1_to_hex(result_sha1));
break;
}
flushes--;
}
}
- pclose(revs);
packet_write(fd[1], "done\n");
if (verbose)
fprintf(stderr, "done\n");
@@ -109,7 +183,8 @@ static int find_common(int fd[2], unsign
flushes--;
if (get_ack(fd[0], result_sha1)) {
if (verbose)
- fprintf(stderr, "got ack\n");
+ fprintf(stderr, "got ack %s\n",
+ sha1_to_hex(result_sha1));
return 0;
}
}
---
0.99.8.GIT
^ permalink raw reply related
* Re: rsync update appears broken now
From: Stephen C. Tweedie @ 2005-10-20 15:03 UTC (permalink / raw)
To: Randal L. Schwartz; +Cc: Stephen Tweedie, git
In-Reply-To: <86vezs9wy9.fsf@blue.stonehenge.com>
Hi,
On Thu, 2005-10-20 at 05:47 -0700, Randal L. Schwartz wrote:
> Doing my daily git-pull now broke in this way (using yesterday's git version):
> ...
> * committish: 6e1c6c103c522d01829f3a63992a023ff031e851
> branch 'master' of rsync://rsync.kernel.org/pub/scm/git/git
> * refs/heads/origin: does not fast forward to branch 'master' of rsync://rsync.kernel.org/pub/scm/git/git;
> not updating.
Seen here too. My HEAD and HEAD^ as of yesterday's pull was:
commit ea5a65a59916503d2a14369c46b1023384d51645
Author: Junio C Hamano <junkio@cox.net>
Date: Tue Oct 18 18:42:19 2005 -0700
Do not ask for objects known to be complete.
On top of optimization by Linus not to ask refs that already match, we
can walk our refs and not issue "want" for things that are known to be
reachable from them.
Signed-off-by: Junio C Hamano <junkio@cox.net>
commit f8765797a41a39f4dfc7030098c38283e6461a83
Author: Junio C Hamano <junkio@cox.net>
Date: Tue Oct 18 18:42:14 2005 -0700
Even when overwriting tags, report if they are changed or not.
Signed-off-by: Junio C Hamano <junkio@cox.net>
Today, looking at git-web I can see that that HEAD^ commit is still
there, but yesterday's HEAD is simply not in the commit chain any more:
there are a couple of other commits and then the "Do not ask for objects
known to be complete" commit appears with SHA
49bb805e69f97e75472e54a68e9eb24e08dee011.
Somebody broke this by rsyncing a non-superset tree to kernel.org,
maybe?
"git reset --hard HEAD^" got rid of the missing HEAD commit and allowed
me to pull from the new commit chain, but that really shouldn't be
necessary.
--Stephen
^ permalink raw reply
* Re: rsync update appears broken now
From: Alex Riesen @ 2005-10-20 14:24 UTC (permalink / raw)
To: Randal L. Schwartz; +Cc: git
In-Reply-To: <86ek6g9t0a.fsf@blue.stonehenge.com>
On 20 Oct 2005 07:12:53 -0700, Randal L. Schwartz <merlyn@stonehenge.com> wrote:
> Alex> Absolutely normal pull into a changed repository. Just fix the
> Alex> conflict (in fetch-pack.c, look for >>>), git-update-index the file
> Alex> and commit. Doesn't look like a problem at all.
>
> What do you mean "changed repository"? This is my git image, and I'm
> not working on git. I made no changes.
>
> Thus, something broken?
>
Not necessarily (I see this every morning, but I know precisely I
touched the sources).
Maybe local damage? What does git-status show?
^ permalink raw reply
* Re: rsync update appears broken now
From: Morten Welinder @ 2005-10-20 14:15 UTC (permalink / raw)
To: Randal L. Schwartz; +Cc: git
In-Reply-To: <86vezs9wy9.fsf@blue.stonehenge.com>
I see the very same with an http pull.
Morten
^ permalink raw reply
* Re: rsync update appears broken now
From: Randal L. Schwartz @ 2005-10-20 14:12 UTC (permalink / raw)
To: Alex Riesen; +Cc: git
In-Reply-To: <81b0412b0510200608l61c00ed0yd4dbc00c313665fe@mail.gmail.com>
>>>>> "Alex" == Alex Riesen <raa.lkml@gmail.com> writes:
Alex> Absolutely normal pull into a changed repository. Just fix the
Alex> conflict (in fetch-pack.c, look for >>>), git-update-index the file
Alex> and commit. Doesn't look like a problem at all.
What do you mean "changed repository"? This is my git image, and I'm
not working on git. I made no changes.
Thus, something broken?
--
Randal L. Schwartz - Stonehenge Consulting Services, Inc. - +1 503 777 0095
<merlyn@stonehenge.com> <URL:http://www.stonehenge.com/merlyn/>
Perl/Unix/security consulting, Technical writing, Comedy, etc. etc.
See PerlTraining.Stonehenge.com for onsite and open-enrollment Perl training!
^ permalink raw reply
* Re: rsync update appears broken now
From: Alex Riesen @ 2005-10-20 13:08 UTC (permalink / raw)
To: Randal L. Schwartz; +Cc: git
In-Reply-To: <86vezs9wy9.fsf@blue.stonehenge.com>
On 20 Oct 2005 05:47:42 -0700, Randal L. Schwartz <merlyn@stonehenge.com> wrote:
>
> Doing my daily git-pull now broke in this way (using yesterday's git version):
>
> sent 1196 bytes received 155984 bytes 4555.94 bytes/sec
> total size is 4511741 speedup is 28.70
> * committish: 6e1c6c103c522d01829f3a63992a023ff031e851
> branch 'master' of rsync://rsync.kernel.org/pub/scm/git/git
> * refs/heads/origin: does not fast forward to branch 'master' of rsync://rsync.kernel.org/pub/scm/git/git;
> not updating.
> Trying really trivial in-index merge...
> fatal: Merge requires file-level merging
> Nope.
> Trying simple merge.
> Simple merge failed, trying Automatic merge.
> Auto-merging fetch-pack.c.
> merge: warning: conflicts during merge
> ERROR: Merge conflict in fetch-pack.c.
> fatal: merge program failed
> Automatic merge failed; fix up by hand
Absolutely normal pull into a changed repository. Just fix the
conflict (in fetch-pack.c, look for >>>), git-update-index the file
and commit. Doesn't look like a problem at all.
^ permalink raw reply
* rsync update appears broken now
From: Randal L. Schwartz @ 2005-10-20 12:47 UTC (permalink / raw)
To: git
Doing my daily git-pull now broke in this way (using yesterday's git version):
sent 1196 bytes received 155984 bytes 4555.94 bytes/sec
total size is 4511741 speedup is 28.70
* committish: 6e1c6c103c522d01829f3a63992a023ff031e851
branch 'master' of rsync://rsync.kernel.org/pub/scm/git/git
* refs/heads/origin: does not fast forward to branch 'master' of rsync://rsync.kernel.org/pub/scm/git/git;
not updating.
Trying really trivial in-index merge...
fatal: Merge requires file-level merging
Nope.
Trying simple merge.
Simple merge failed, trying Automatic merge.
Auto-merging fetch-pack.c.
merge: warning: conflicts during merge
ERROR: Merge conflict in fetch-pack.c.
fatal: merge program failed
Automatic merge failed; fix up by hand
--
Randal L. Schwartz - Stonehenge Consulting Services, Inc. - +1 503 777 0095
<merlyn@stonehenge.com> <URL:http://www.stonehenge.com/merlyn/>
Perl/Unix/security consulting, Technical writing, Comedy, etc. etc.
See PerlTraining.Stonehenge.com for onsite and open-enrollment Perl training!
^ permalink raw reply
* Re: Revamping the git protocol
From: Petr Baudis @ 2005-10-20 9:12 UTC (permalink / raw)
To: Junio C Hamano; +Cc: H. Peter Anvin, git
In-Reply-To: <7vwtk8pvju.fsf@assigned-by-dhcp.cox.net>
Dear diary, on Thu, Oct 20, 2005 at 08:11:17AM CEST, I got a letter
where Junio C Hamano <junkio@cox.net> told me that...
> I am wondering if we can just get away with a simpler scheme
> Linus outlined instead. One drawback of that approach is it
> does not easily allow things like challenge-response uniformly
> across different commands (admittedly we only have "upload-pack"
> command right now, but we could add list of supported commands
> easily in execute()), but you could do something along this, I
> presume?
What's wrong with my scheme? That is, _reply_ with challenge to the
upload-pack command. This should be equally powerful to the Linus'
scheme and the crucial advantage is that you do not need to tell at
the client side whether you are talking to a new server or an old one.
I was convinced that the authentication part of the challenge-resposne
isn't such a good idea after all, though. ;-)
--
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
* Re: git-snapshot.sh
From: Petr Baudis @ 2005-10-20 9:01 UTC (permalink / raw)
To: Nico -telmich- Schottelius; +Cc: git
In-Reply-To: <20051017220615.GG12774@schottelius.org>
Hello,
Dear diary, on Tue, Oct 18, 2005 at 12:06:15AM CEST, I got a letter
where Nico -telmich- Schottelius <nico-linux-git@schottelius.org> told me that...
> I really like to have a snapshot available from my sources in VCS.
>
> Therefore I wrote the attached script.
>
> Just wanted to send it, perhaps someone can use it.
and the others can use
cg-export snapshot.tar.bz2
;-)
--
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
* Re: How do I clear the directory cache
From: Petr Baudis @ 2005-10-20 8:59 UTC (permalink / raw)
To: eschvoca; +Cc: git
In-Reply-To: <2b05065b0510170720n5333f03l1941e84c1288fc5d@mail.gmail.com>
Hello,
Dear diary, on Mon, Oct 17, 2005 at 04:20:42PM CEST, I got a letter
where eschvoca <eschvoca@gmail.com> told me that...
> If I do a:
>
> cg-commit
> modifiy some files
> cg-rm <modified files>
> cg-add <a new file>
> cg-rm <a unmodified file>
>
> Then how do I get back and undo all of the cg-adds and cg-rms? I want
> cg-status to show the the changes from my commit and my current
> working tree.
why can't you just do the following?
cg-add <an unmodified file>
cg-rm <a new file>
cg-add <modified files>
Hmm. Would it be non-marginally useful to offer something like
cg-reset --adds-removals
to just reset the index? (It's not --index because Cogito users aren't
supposed to have to know what an "index" is.)
--
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
* [PATCH] git-daemon: fix poll timeout
From: Timo Hirvonen @ 2005-10-20 8:33 UTC (permalink / raw)
To: Git Mailing List, Junio C Hamano
Timeout must be negative (infinite), not 0.
---
daemon.c | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
applies-to: 50f9bed9a78e1f51178ebf6be3cd9c20b2ffcb0b
a6603be778e535b12f7aa42174889981af42b10c
diff --git a/daemon.c b/daemon.c
index c3381b3..b3bcd7a 100644
--- a/daemon.c
+++ b/daemon.c
@@ -533,7 +533,7 @@ static int service_loop(int socknum, int
for (;;) {
int i;
- if (poll(pfd, socknum, 0) < 0) {
+ if (poll(pfd, socknum, -1) < 0) {
if (errno != EINTR) {
error("poll failed, resuming: %s",
strerror(errno));
---
0.99.8.GIT
^ permalink raw reply related
* Re: The git protocol and DoS
From: Andreas Ericsson @ 2005-10-20 8:16 UTC (permalink / raw)
To: Git Mailing List
In-Reply-To: <20051019222044.GP30889@pasky.or.cz>
Petr Baudis wrote:
> Dear diary, on Wed, Oct 19, 2005 at 10:00:05PM CEST, I got a letter
> where "H. Peter Anvin" <hpa@zytor.com> told me that...
>
>>One way to do this would be to start the transaction by having the
>>server transmit a cookie to the client, and to require the client to
>>send a SHA1 of the (cookie + request) together with the request. This
>>would be done with a fairly short timeout.
>
>
> If (well, it sounds like a good idea, so rather "when") you do this,
> it would be a good idea to do in a way that makes it easy to later add
> support for some kind of authentication (really, not everyone wants to
> give away ssh accounts). Let's say it works like:
>
> [client] git-upload-pack <path>
> [server] challenge somethingnonsensical
> [client] challenge-response <username>:sha1(somethingnonsensical<password>)
> [server] All right, the pack goes like this...
>
> Suddenly you have support for hopefully secure authentication, and at
> the same time you have the cookie implemented in backwards-compatible
> fashion (in the sense that new client will be able to talk to old
> server) - just assume the username and password empty. This might be
> even hardcoded for now, just leave a room for its addition (in an
> elegant and compatible way) in the protocol, please.
>
I think git-daemon would be better off without this, since
* A project rarely grants write access to the central repo (or whatever
git has, I'm still fairly new to it) without being willing to give out
ssh access, often limited by the ssh command whitelist.
* It's hard to do right.
* Passwords are never as secure or as convenient as public key
authentication and there's no point in spending a lot of time
re-inventing ssh.
--
Andreas Ericsson andreas.ericsson@op5.se
OP5 AB www.op5.se
Tel: +46 8-230225 Fax: +46 8-230231
^ permalink raw reply
* Re: cg-merge should use git-merge
From: Martin Langhoff @ 2005-10-20 7:04 UTC (permalink / raw)
To: Git Mailing List, Petr Baudis, Junio C Hamano
In-Reply-To: <46a038f90510190421l50b2c12k495db23b62015782@mail.gmail.com>
On 10/20/05, Martin Langhoff <martin.langhoff@gmail.com> wrote:
> After using git-merge a few times by hand to test-drive the new merge
> drivers, I'm sold on the idea, and I 'd like to have cg-merge use
> git-merge directly.
I started drafting a 5-minute proof-of-concept, and then it struck me:
cg users aren't aware of the index. This is really important when you
are merging and have to resolve a conflict over a dirty tree. git
users know that the "clean" part of the merge is in the index, and
they have to resolve a couple of files in their checkout, and update
the index for those only before calling git-write-tree &
git-commit-tree.
Cogito users don't know about this magic at all, which is a bit of a
problem. I can refuse to run cg-merge on a dirty tree to make things
simpler, but that's cheating ;-)
tagging "for later"...
cheers,
martin
^ permalink raw reply
* Re: Revamping the git protocol
From: Junio C Hamano @ 2005-10-20 6:11 UTC (permalink / raw)
To: H. Peter Anvin; +Cc: git
In-Reply-To: <43571DA1.6030907@zytor.com>
Wow.
That's elaborate. And all this is to replace the beginning of
execute() part of daemon.c? What I am assuming is that after
exchanging command-response initially, you still plan to
eventually have the protocol driver such as upload-pack to take
things over, once "send-pack <path>" is issued, but is my
assumption correct? Or are you also thinking about redoing
upload-pack as well (otherwise you cannot issue 5.4 errors)?
I am wondering if we can just get away with a simpler scheme
Linus outlined instead. One drawback of that approach is it
does not easily allow things like challenge-response uniformly
across different commands (admittedly we only have "upload-pack"
command right now, but we could add list of supported commands
easily in execute()), but you could do something along this, I
presume?
When daemon is started with --require-challenge-response,
the client needs to issue "challenge-me" command and complete
challenge_response successfully before being able to issue any
other commands.
NOTE: this is just an outline, not a compilable patch. You need to
fill in the details of challenge response, definition of
"require_challenge_response" variable of type bool, and a
command line parsing to set that variable.
---
git diff
diff --git a/daemon.c b/daemon.c
index c3381b3..8a8746a 100644
--- a/daemon.c
+++ b/daemon.c
@@ -204,20 +204,55 @@ static int upload(char *dir)
return -1;
}
-static int execute(void)
+static int challenge_response(const char *me)
{
- static char line[1000];
- int len;
+ char line[1000];
- alarm(init_timeout ? init_timeout : timeout);
+ packet_write(1, "here comes your challenge");
+
+ alarm(timeout);
len = packet_read_line(0, line, sizeof(line));
alarm(0);
if (len && line[len-1] == '\n')
line[--len] = 0;
- if (!strncmp("git-upload-pack /", line, 17))
- return upload(line+16);
+ if ("validate response we obtained in line here")
+ return 1;
+ return 0;
+}
+
+static int execute(void)
+{
+ static char line[1000];
+ int len;
+ int client_ok = !require_challenge_response;
+ unsigned int time_out = init_timeout;
+
+ while (1) {
+
+ alarm(time_out);
+ time_out = timeout;
+ len = packet_read_line(0, line, sizeof(line));
+ alarm(0);
+ if (len && line[len-1] == '\n')
+ line[--len] = 0;
+
+ if (!strncmp("challenge-me ", line, 13)) {
+ client_ok = challenge_response(line+13);
+ continue;
+ }
+
+ if (!client_ok)
+ break;
+
+ if (!strncmp("git-upload-pack /", line, 17))
+ return upload(line+16);
+
+ /* more commands here later */
+
+ break;
+ }
logerror("Protocol error: '%s'", line);
return -1;
^ permalink raw reply related
* Re: [PATCH] cg-fetch will now retrieve commits related to tags if missing.
From: Junio C Hamano @ 2005-10-20 5:23 UTC (permalink / raw)
To: Martin Langhoff; +Cc: Martin Langhoff, git
In-Reply-To: <46a038f90510192159h25aad025kf377e3e33b5d30d@mail.gmail.com>
Martin Langhoff <martin.langhoff@gmail.com> writes:
> Ok -- I was using ^{commit} which _is_ lazy, but you are
> right, ^0 isn't lazy.
Ah, my mistake. We would need something like this.
---
diff --git a/sha1_name.c b/sha1_name.c
index 75c688e..cc320d3 100644
--- a/sha1_name.c
+++ b/sha1_name.c
@@ -323,6 +323,8 @@ static int peel_onion(const char *name,
return -1;
if (!type_string) {
o = deref_tag(o);
+ if (!o || (!o->parsed && !parse_object(o->sha1)))
+ return -1;
memcpy(sha1, o->sha1, 20);
}
else {
@@ -332,7 +334,7 @@ static int peel_onion(const char *name,
*/
while (1) {
- if (!o)
+ if (!o || (!o->parsed && !parse_object(o->sha1)))
return -1;
if (o->type == type_string) {
memcpy(sha1, o->sha1, 20);
^ permalink raw reply related
* Re: [PATCH] cg-fetch: handle tags with funny chars, retrieve missing commits
From: Martin Langhoff @ 2005-10-20 5:05 UTC (permalink / raw)
To: Git Mailing List, Petr Baudis
In-Reply-To: <11297835242417-git-send-email-martin@catalyst.net.nz>
Pulled, superceded by new version.
On 10/20/05, Martin Langhoff <martin@catalyst.net.nz> wrote:
> + handles tags with funny chars a bit better
> + will check tagrefs, trying to ensure it actually has the relevant
> commits. If the commits are missing, it'll go out and fetch them.
>
> This isn't a complete solution for cg-fetch -- git-fetch is actually
> much smarter now, and cg-fetch should perhaps be a thin wrapper
> around it, dropping all the duplicate code.
>
> Signed-off-by: Martin Langhoff <martin@catalyst.net.nz>
^ permalink raw reply
* [PATCH] cg-fetch: handle tags with funny chars, retrieve missing commits
From: Martin Langhoff @ 2005-10-20 5:07 UTC (permalink / raw)
To: git; +Cc: Martin Langhoff
+ handles tags with funny chars a bit better
+ will check tagrefs, trying to ensure it actually has the relevant
commits. If the commits are missing, it'll go out and fetch them.
+ if the tagref points to a blob and we have it, it'll skip it
This isn't a complete solution for cg-fetch -- git-fetch is actually
much smarter now, and cg-fetch should perhaps be a thin wrapper
around it, dropping all the duplicate code.
This version uses ^0 instead of ^{commit} which does a more thorough check,
so we don't need to call git-cat-file.
Signed-off-by: Martin Langhoff <martin@catalyst.net.nz>
---
cg-fetch | 5 +++--
1 files changed, 3 insertions(+), 2 deletions(-)
applies-to: 38ed7981343a8e2bb734d64e019186a8a482dbef
6adda5a9a938adbc313c6ed40156257d62707757
diff --git a/cg-fetch b/cg-fetch
index 7694584..ec9fff3 100755
--- a/cg-fetch
+++ b/cg-fetch
@@ -416,8 +416,9 @@ $get -i -s -u -d "$uri/refs/tags" "$_git
cd $_git/refs/tags
for tag in *; do
[ "$tag" = "*" ] && break
- tagid=$(cat $tag)
- GIT_DIR=../.. git-cat-file -t "$tagid" >/dev/null 2>&1 && continue
+ tagid=$(cat "$tag")
+ GIT_DIR=../.. git-rev-parse --verify "$tag"^0 2>/dev/null >> /dev/null && continue
+ GIT_DIR=../.. git-cat-file blob `git-rev-parse --verify "$tag"^{blob} 2>/dev/null` 2>/dev/null >> /dev/null && continue
echo -n "Missing object of tag $tag... "
if [ "$fetch" != "fetch_rsync" ] && GIT_DIR=../.. $fetch "$tagid" "$uri" 2>/dev/null >&2; then
echo "retrieved"
---
0.99.8.GIT
^ 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