* [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
* Re: [PATCH] cg-fetch will now retrieve commits related to tags if missing.
From: Martin Langhoff @ 2005-10-20 4:59 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Martin Langhoff, git
In-Reply-To: <7virvsu79c.fsf@assigned-by-dhcp.cox.net>
On 10/20/05, Junio C Hamano <junkio@cox.net> wrote:
> Martin Langhoff <martin.langhoff@gmail.com> writes:
>
> >> GIT_DIR=../.. git-rev-parse --verify "$tagid^0" >/dev/null 2>&1 && continue
> >
> > Note however that git-rev-parse is lazy and won't check that the
> > commit is there. I have to call git-cat-file and check whether it
> > succeeds to know if we have the object.
>
> Are you sure?
>
> What "rev^0" does is:
Ok -- I was using ^{commit} which _is_ lazy, but you are right, ^0 isn't lazy.
> BTW, I just got a SEGV while pulling Cogito repository over
> git-fetch-pack after interrupting rsync transfer (I wanted to
> switch to git transfer). I am running with Johaness patch from
> today so the cause may be different from yours, but now I have
> something to look at, which is better than before.
>
> Fetching with rsync (and interrupting in the middle) is a good
> way to simulate a broken repository ;-).
Cool. That's something for you to play with I guess, to tell you the
truth, I'm not useful with gdb ;)
martin
^ permalink raw reply
* Re: [PATCH] cg-fetch will now retrieve commits related to tags if missing.
From: Junio C Hamano @ 2005-10-20 4:44 UTC (permalink / raw)
To: Martin Langhoff; +Cc: Martin Langhoff, git
In-Reply-To: <46a038f90510192118s31c52fe7m73d88a9779653f4c@mail.gmail.com>
Martin Langhoff <martin.langhoff@gmail.com> writes:
>> GIT_DIR=../.. git-rev-parse --verify "$tagid^0" >/dev/null 2>&1 && continue
>
> Note however that git-rev-parse is lazy and won't check that the
> commit is there. I have to call git-cat-file and check whether it
> succeeds to know if we have the object.
Are you sure?
What "rev^0" does is:
1. parse "rev"; make sure it can deref to commit and read
it (otherwise give up and say the whole thing is not an
SHA1 expression);
2. grab the nth parent SHA1. If N>0, it is lazy and does
not check if the parent object exists, but still 0th
parent is the commit object itself and if we came this
far you know that commit is available already.
Together with --verify, it barfs if the above does not say "rev^0"
is a valid SHA1 expression. So this should work without
cat-file. No?
BTW, I just got a SEGV while pulling Cogito repository over
git-fetch-pack after interrupting rsync transfer (I wanted to
switch to git transfer). I am running with Johaness patch from
today so the cause may be different from yours, but now I have
something to look at, which is better than before.
Fetching with rsync (and interrupting in the middle) is a good
way to simulate a broken repository ;-).
^ permalink raw reply
* [PATCH] cg-fetch: handle tags with funny chars, retrieve missing commits
From: Martin Langhoff @ 2005-10-20 4:45 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.
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>
---
cg-fetch | 5 +++--
1 files changed, 3 insertions(+), 2 deletions(-)
applies-to: 38ed7981343a8e2bb734d64e019186a8a482dbef
21a91d74a6807677f8e59c737fee3692d0f392e8
diff --git a/cg-fetch b/cg-fetch
index 7694584..625444c 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-cat-file commit `git-rev-parse --verify "$tag"^{commit} 2>/dev/null` 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
* Revamping the git protocol
From: H. Peter Anvin @ 2005-10-20 4:31 UTC (permalink / raw)
To: Git Mailing List
Okay, so I've started thinking about what it would take to revamp the
git protocol. What I came up with seems a little complex, but all it
really is is take the framework that most successful Internet protocols
have used and applied it to git.
Something else that I've noticed is that there is functionality overlap
between git-daemon and git-send-pack, such as the namespace management
(DWIM functionality.) Additionally, even when using git over ssh there
is the potential for version skew, so it might be worthwhile to run the
full protocol over ssh as well.
Anyway, here is a strawman. Items I feel unsure about I've put in brackets.
----------
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>.
2. Upon connection, the server will issue a sequence of strings,
terminated by a null string. The first string will be of the format:
"git <x.y>[ <hostname>]"
x.y is protocol revision (currently 1.0) with the following semantics:
- a change in x indicates a fully incompatible protocol change which
means a client which doesn't understand the exact x version should
immediately disconnect without issuing any output.
- a change in y indicates a backward-compatible protocol change which
menas a client which understands an older version of the protocol can
still communicate.
- hostname is an optional canonical name for this server.
For protocol version 1.0, subsequent strings are of the form:
"<R|O|I> option[ <parameters...>]"
... where the letter indicates REQUIRED, OPTIONAL or INFORMATIVE. If a
server specifies a REQUIRED option which the client does not understand
or support, the CLIENT should terminate with an "unable" command (see
below). An OPTIONAL option is available to the client should it choose
to accept it. An INFORMATIVE option has no protocol function, but may
be used to tune the client, inform the client of server policies (such
as timeouts) or display to the end user if the client is in verbose mode.
Note that the addition of options does not require a new protocol
revision. It is generally believed that the protocol revision will
rarely, if ever, be changed.
2a. Option "challenge":
"R challenge <seed>"
... where 'seed' is any sequence of bytes means that the client should
compute the SHA-1 of the seed and issue a "response" command with the
SHA1 in hexadecimal form before issuing any other command.
3. After receiving the list of options, the client can issue commands.
Commands are strings beginning with a command, one space, and any
arguments as appropriate to the command.
4. The response to a command is a string beginning with a dot-separated
sequence of numbers, one space, and an optional human-readable text
string. Each part of the dot-separated sequence refines the response;
if a client receives "3.1.1.6 foo" and doesn't know what it is, but
knows what a "3.1" response is, it should treat the 3.1.1.6 response as
a 3.1 response.
If the server is closing the connection, the response is prefixed with
the letter 'C':
"C5.0.1 Incorrect response"
Future versions of the protocol might define new prefix letters; if a
client encounters unknown prefix letters they should be ignored.
2 - successful completion, closing connection
3 - successful initiation, begin transaction
4 - transient error
4.1 - server resource exhaustion errors
4.1.1 - load too high
5 - permanent error
5.1 - protocol errors
5.2 - authentication error
5.2.1 - invalid reponse to challenge option
5.3 - permission errors
5.3.1 - repository access denied
5.4 - data integrity error
5.4.1 - invalid or corrupt repository
5. Commands, and their responses:
"response <sha1>"
... response to a "challenge" option. Responses:
"2.0 OK" - response accepted
"C5.2.1 Invalid response" - invalid response
"unable <human error message>"
... error message from the client to the server due to an unsupported R
option. Sending this message can inform the server administrator of
version skew problems.
Response:
"C5.1.1 Too bad"
"send-pack <path>"
... begin synchronization of the repository at <path>. Responses:
"3.1.1 Begin"
Any 4.1 response
Any 5.3 or 5.4 response
Clearly this needs to be fleshed out a bit more... is this total
insanity on my part, or is this something worth doing?
-hpa
^ permalink raw reply
* Re: [PATCH] cg-fetch will now retrieve commits related to tags if missing.
From: Martin Langhoff @ 2005-10-20 4:18 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Martin Langhoff, git
In-Reply-To: <7voe5lvv1q.fsf@assigned-by-dhcp.cox.net>
On 10/20/05, Junio C Hamano <junkio@cox.net> wrote:
> You are saying:
> if "$tagid" is already commit then continue;
> if "$tagid" dereferences to a commit and if you have it
> then continue
>
> If that is the case, then this might be more efficient.
>
> GIT_DIR=../.. git-rev-parse --verify "$tagid^0" >/dev/null 2>&1 && continue
Note however that git-rev-parse is lazy and won't check that the
commit is there. I have to call git-cat-file and check whether it
succeeds to know if we have the object.
cheers,
martin
^ permalink raw reply
* Re: [PATCH] Do not send "want" lines for complete objects
From: Junio C Hamano @ 2005-10-20 4:16 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: git
In-Reply-To: <Pine.LNX.4.63.0510200559540.3394@wbgn013.biozentrum.uni-wuerzburg.de>
Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
> Hi,
>
>> > + ((o = parse_object(remote)) != NULL) &&
>> > + (o->flags & COMPLETE) &&
>
> I just realized that parse_object() always reads the file, then does a
> lookup (which makes the above code work), and then parses the file. It
> always does all of these steps, even if the object was already parsed. Any
> reason for this?
You are right. We should be using lookup_object() for this part
of the code.
^ permalink raw reply
* Re: [PATCH] cg-fetch will now retrieve commits related to tags if missing.
From: Martin Langhoff @ 2005-10-20 4:15 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Martin Langhoff, git
In-Reply-To: <7voe5lvv1q.fsf@assigned-by-dhcp.cox.net>
On 10/20/05, Junio C Hamano <junkio@cox.net> wrote:
> You just reported this $tag needs quoting ;-).
I thought I had seen a post from you to Petr, mentioning that he had
just fixed it. I didn't see any fix when I updated, but I thought it
may have been due to mirroring issues. In any case, it obviously needs
quoting.
> > + GIT_DIR=../.. [ "`git-cat-file -t $tagid 2>/dev/null`" = "commit" ] && continue
> > + GIT_DIR=../.. git-cat-file commit `git-rev-parse $tag^{commit} 2>/dev/null` 2>&1 >> /dev/null && continue
>
> You are saying:
> if "$tagid" is already commit then continue;
> if "$tagid" dereferences to a commit and if you have it
> then continue
>
> If that is the case, then this might be more efficient.
>
> GIT_DIR=../.. git-rev-parse --verify "$tagid^0" >/dev/null 2>&1 && continue
>
> You can say ^{commit} instead of ^0 if you like that newer
> style, of course.
I tried, and failed to get it to work 100% so I reverted to the double
check you've seen. Must have been PEBKAC for now it works correctly --
possibly related to the unquoted tagnames.
Ok -- too many problems with that patch. Let's try it again...
martin
^ permalink raw reply
* Re: [PATCH] Do not send "want" lines for complete objects
From: Johannes Schindelin @ 2005-10-20 4:08 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <Pine.LNX.4.63.0510200351260.26594@wbgn013.biozentrum.uni-wuerzburg.de>
Hi,
> > + ((o = parse_object(remote)) != NULL) &&
> > + (o->flags & COMPLETE) &&
I just realized that parse_object() always reads the file, then does a
lookup (which makes the above code work), and then parses the file. It
always does all of these steps, even if the object was already parsed. Any
reason for this?
Ciao,
Dscho
^ permalink raw reply
* man page for git push --all
From: Chris Shoemaker @ 2005-10-20 2:36 UTC (permalink / raw)
To: git
FYI,
Synopsis for git-push includes [--all] (but no [--append]).
Actual option descriptions include --append but don't mention --all.
So, what does --all, do?
-chris
^ permalink raw reply
* Re: [PATCH] Do not send "want" lines for complete objects
From: Johannes Schindelin @ 2005-10-20 2:04 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vwtk9vvhg.fsf@assigned-by-dhcp.cox.net>
Hi,
On Wed, 19 Oct 2005, Junio C Hamano wrote:
> Junio C Hamano <junkio@cox.net> writes:
>
> > Let's draw a single strand of pearl case to illustrate. You
> > have a commit chain A->B->C->D, and the other end says she has
> > C. At this point, telling her that you have C is enough, and by
> > not telling her about A and B, you would save her from depreting
> > MAX_HAVE slots. Of course, if the other end has D as another
> > head, then the above logic would give "^D^" to rev-list as well,
> > telling it not to tell her about C, but that is what we want --
> > because she already knows you have C too when you tell her that
> > you have D. I think I like this optimization.
>
> This was subtly wrong. ^D^ would barf if D is a tag that points
> at a non commit (refs/tags/v2.6.11-tree). Also it would do a
> suboptimal thing for a merge commit, since it will not cull the
> second and later parents.
Right, I keep forgetting about tags. And again right, like I said, it is
suboptimal but helps the common case.
> + if (has_sha1_file(remote) &&
> + ((o = parse_object(remote)) != NULL) &&
> + (o->flags & COMPLETE) &&
Why not split it here, and do a separate block here:
> + ((commit = (struct commit *) deref_tag(o)) != NULL) &&
> + (commit->object.type = commit_type)) {
> + struct commit_list *p = commit->parents;
> + while (p && rev_command_len + 44 < sizeof(rev_command)) {
> snprintf(rev_command + rev_command_len, 44,
> - " ^%s^", sha1_to_hex(remote));
> + " ^%s",
> + sha1_to_hex(p->item->object.sha1));
> rev_command_len += 43;
> + p = p->next;
> }
And here I am at a loss: why only continue if p is empty? I mean, remote
could be a tag, and still be complete, no?
> -
> - continue;
> + if (!p)
> + continue;
> }
>
> packet_write(fd[1], "want %s\n", sha1_to_hex(remote));
>
If the git-rev-list call goes, this probably gets prettier. I'll try to
come up with a patch.
Ciao,
Dscho
^ permalink raw reply
* Re: [PATCH] Do not send "want" lines for complete objects
From: Johannes Schindelin @ 2005-10-20 1:51 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vzmp5xfwu.fsf@assigned-by-dhcp.cox.net>
Hi,
On Wed, 19 Oct 2005, Junio C Hamano wrote:
> Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
>
> > Also, git-fetch-pack does not have to ask for descendants of remote refs
> > which are complete (for now, git-rev-list is told to ignore only the first
> > parent).
>
> I should interpret what you said with s/descendant/ancestor/
> applied, I think. I would like to make sure I understand what
> you are doing here.
Sure. You are thinking along chronological lines. Okay.
> > + if (has_sha1_file(remote)
> > + && parse_object(remote)->flags & COMPLETE) {
> > + if (rev_command_len + 44 < sizeof(rev_command)) {
> > + snprintf(rev_command + rev_command_len, 44,
> > + " ^%s^", sha1_to_hex(remote));
> > + rev_command_len += 43;
> > + }
>
> This rev-list command is to generate the list of "have", and we
> learned that the other side says she has remote -- we choose not
> to tell her that we have ancestors of it, but we do tell her
> about the remote head itself.
>
> Let's draw a single strand of pearl case to illustrate. You
> have a commit chain A->B->C->D, and the other end says she has
> C. At this point, telling her that you have C is enough, and by
> not telling her about A and B, you would save her from depreting
> MAX_HAVE slots. Of course, if the other end has D as another
> head, then the above logic would give "^D^" to rev-list as well,
> telling it not to tell her about C, but that is what we want --
> because she already knows you have C too when you tell her that
> you have D. I think I like this optimization.
>
> One thing that might help, when we are telling the other end
> about what we have, is an output ordering option to get-rev-list
> that shows not in chronological order, but in the order of
> distance from the tip. That may give the other end a better
> chance to find the latest (in commit order) common commit in
> each branch without running out is MAX_HAS buffer.
That was my idea.
Ciao,
Dscho
^ permalink raw reply
* Re: Problem getting older version
From: Petr Baudis @ 2005-10-20 1:42 UTC (permalink / raw)
To: Nico -telmich- Schottelius; +Cc: git
In-Reply-To: <20051019080046.GI22986@schottelius.org>
Hello,
Dear diary, on Wed, Oct 19, 2005 at 10:00:46AM CEST, I got a letter
where Nico -telmich- Schottelius <nico-linux-git@schottelius.org> told me that...
> The following situation:
>
> - The last commit was a merge, mhich broke some files
> - We want three files from the commit before
..snip..
> Is this really the standard way to recover a file? As a developer / end user I would expect that:
>
> cg-recover <filename> <commit id> and -f for overwriting the file if it exists
thanks for the suggestion. I've revamped cg-restore to support this
kind of syntax, so now if you do
cg-restore -r ID [-f] FILENAME
it should do what you want.
--
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: [PATCH] git-daemon: timeout, eliminate double DWIM
From: Petr Baudis @ 2005-10-20 1:26 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vsluxvvdc.fsf@assigned-by-dhcp.cox.net>
Dear diary, on Thu, Oct 20, 2005 at 03:18:39AM CEST, I got a letter
where Junio C Hamano <junkio@cox.net> told me that...
> Petr Baudis <pasky@suse.cz> writes:
>
> > You didn't update Documentation/git-daemon.txt.
> >...
> > Ditto.
>
> Patches welcome.
Ah, I didn't notice it was already merged, sorry.
BTW, some of the commits in your tree have the same author and
committer date while they shouldn't:
author H. Peter Anvin <hpa@zytor.com> Wed, 19 Oct 2005 14:27:01 -0700
committer Junio C Hamano <junkio@cox.net> Wed, 19 Oct 2005 14:27:01 -0700
--
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: [PATCH] cg-fetch will now retrieve commits related to tags if missing.
From: Junio C Hamano @ 2005-10-20 1:25 UTC (permalink / raw)
To: Martin Langhoff; +Cc: git
In-Reply-To: <1129769745158-git-send-email-martin@catalyst.net.nz>
Martin Langhoff <martin@catalyst.net.nz> writes:
> diff --git a/cg-fetch b/cg-fetch
> index 7694584..d4650e5 100755
> --- a/cg-fetch
> +++ b/cg-fetch
> @@ -417,7 +417,8 @@ $get -i -s -u -d "$uri/refs/tags" "$_git
> for tag in *; do
> [ "$tag" = "*" ] && break
> tagid=$(cat $tag)
You just reported this $tag needs quoting ;-).
> + GIT_DIR=../.. [ "`git-cat-file -t $tagid 2>/dev/null`" = "commit" ] && continue
> + GIT_DIR=../.. git-cat-file commit `git-rev-parse $tag^{commit} 2>/dev/null` 2>&1 >> /dev/null && continue
You are saying:
if "$tagid" is already commit then continue;
if "$tagid" dereferences to a commit and if you have it
then continue
If that is the case, then this might be more efficient.
GIT_DIR=../.. git-rev-parse --verify "$tagid^0" >/dev/null 2>&1 && continue
You can say ^{commit} instead of ^0 if you like that newer
style, of course.
^ permalink raw reply
* Re: [PATCH] git-daemon: timeout, eliminate double DWIM
From: Junio C Hamano @ 2005-10-20 1:18 UTC (permalink / raw)
To: Petr Baudis; +Cc: git
In-Reply-To: <20051020002845.GT30889@pasky.or.cz>
Petr Baudis <pasky@suse.cz> writes:
> You didn't update Documentation/git-daemon.txt.
>...
> Ditto.
Patches welcome.
^ permalink raw reply
* Re: [PATCH] Do not send "want" lines for complete objects
From: Junio C Hamano @ 2005-10-20 1:16 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: git
In-Reply-To: <7vzmp5xfwu.fsf@assigned-by-dhcp.cox.net>
Junio C Hamano <junkio@cox.net> writes:
> Let's draw a single strand of pearl case to illustrate. You
> have a commit chain A->B->C->D, and the other end says she has
> C. At this point, telling her that you have C is enough, and by
> not telling her about A and B, you would save her from depreting
> MAX_HAVE slots. Of course, if the other end has D as another
> head, then the above logic would give "^D^" to rev-list as well,
> telling it not to tell her about C, but that is what we want --
> because she already knows you have C too when you tell her that
> you have D. I think I like this optimization.
This was subtly wrong. ^D^ would barf if D is a tag that points
at a non commit (refs/tags/v2.6.11-tree). Also it would do a
suboptimal thing for a merge commit, since it will not cull the
second and later parents.
Maybe something like this on top of your patch? This is turning
out to be quite ugly.
---
diff --git a/fetch-pack.c b/fetch-pack.c
index 9dfd072..5cc3766 100644
--- a/fetch-pack.c
+++ b/fetch-pack.c
@@ -28,20 +28,29 @@ static int find_common(int fd[2], unsign
fetching = 0;
for ( ; refs ; refs = refs->next) {
unsigned char *remote = refs->old_sha1;
-
+ struct object *o;
+ struct commit *commit;
/*
- If that object is complete (i.e. it is a descendant of a
- local ref), we don't want it, nor its descendants.
- */
- if (has_sha1_file(remote)
- && parse_object(remote)->flags & COMPLETE) {
- if (rev_command_len + 44 < sizeof(rev_command)) {
+ * If that object is complete (i.e. it is an ancestor of a
+ * local ref), we tell them we have it but do not have to
+ * tell them about its ancestors, which they already know
+ * about.
+ */
+ if (has_sha1_file(remote) &&
+ ((o = parse_object(remote)) != NULL) &&
+ (o->flags & COMPLETE) &&
+ ((commit = (struct commit *) deref_tag(o)) != NULL) &&
+ (commit->object.type = commit_type)) {
+ struct commit_list *p = commit->parents;
+ while (p && rev_command_len + 44 < sizeof(rev_command)) {
snprintf(rev_command + rev_command_len, 44,
- " ^%s^", sha1_to_hex(remote));
+ " ^%s",
+ sha1_to_hex(p->item->object.sha1));
rev_command_len += 43;
+ p = p->next;
}
-
- continue;
+ if (!p)
+ continue;
}
packet_write(fd[1], "want %s\n", sha1_to_hex(remote));
^ permalink raw reply related
* [PATCH] cg-fetch will now retrieve commits related to tags if missing.
From: Martin Langhoff @ 2005-10-20 0:55 UTC (permalink / raw)
To: git; +Cc: Martin Langhoff
Signed-off-by: Martin Langhoff <martin@catalyst.net.nz>
---
cg-fetch | 3 ++-
1 files changed, 2 insertions(+), 1 deletions(-)
applies-to: 38ed7981343a8e2bb734d64e019186a8a482dbef
48cb643964910a058881307513cb63aeee28a1de
diff --git a/cg-fetch b/cg-fetch
index 7694584..d4650e5 100755
--- a/cg-fetch
+++ b/cg-fetch
@@ -417,7 +417,8 @@ $get -i -s -u -d "$uri/refs/tags" "$_git
for tag in *; do
[ "$tag" = "*" ] && break
tagid=$(cat $tag)
- GIT_DIR=../.. git-cat-file -t "$tagid" >/dev/null 2>&1 && continue
+ GIT_DIR=../.. [ "`git-cat-file -t $tagid 2>/dev/null`" = "commit" ] && continue
+ GIT_DIR=../.. git-cat-file commit `git-rev-parse $tag^{commit} 2>/dev/null` 2>&1 >> /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
* Re: git-send-pack segfaulting on DebianPPC (was: Re: cg-clone, tag objects and cg-push/git-push don't play nice)
From: Martin Langhoff @ 2005-10-20 0:43 UTC (permalink / raw)
To: Petr Baudis; +Cc: git
In-Reply-To: <20051019235208.GR30889@pasky.or.cz>
On 10/20/05, Petr Baudis <pasky@suse.cz> wrote:
> Dear diary, on Thu, Oct 20, 2005 at 01:23:11AM CEST, I got a letter
> where Martin Langhoff <martin.langhoff@gmail.com> told me that...
> > Actually, all the tagsrefs have only one line, but something is going
> > weird around tagid=$(cat $tag) as $tag ends up containing many
> > filenames. So I undid my initial change to "head -n1", and I'm trying
> > to fix the loop.
>
> Hmm, what bash version are you using? It's enclosed in
>
> for tag in *
>
> and perhaps your bash misunderstood.
After a bit of head-scratching, I found out what was causing this one:
legacy tagnames from git-cvsimport that contain '*' in the tagname. So
tagid=$(cat SOME_TAG **INVALID**)
gives us some really nasty surprises.
cheers,
martin
^ permalink raw reply
* Re: [PATCH] git-daemon: timeout, eliminate double DWIM
From: Petr Baudis @ 2005-10-20 0:28 UTC (permalink / raw)
To: H. Peter Anvin; +Cc: Git Mailing List
In-Reply-To: <4356966A.8010401@zytor.com>
Dear diary, on Wed, Oct 19, 2005 at 08:54:34PM CEST, I got a letter
where "H. Peter Anvin" <hpa@zytor.com> told me that...
> diff --git a/daemon.c b/daemon.c
> --- a/daemon.c
> +++ b/daemon.c
> @@ -13,7 +13,9 @@
> static int log_syslog;
> static int verbose;
>
> -static const char daemon_usage[] = "git-daemon [--verbose] [--syslog] [--inetd | --port=n] [--export-all] [directory...]";
> +static const char daemon_usage[] =
> +"git-daemon [--verbose] [--syslog] [--inetd | --port=n] [--export-all]\n"
> +" [--timeout=n] [--init-timeout=n] [directory...]";
>
> /* List of acceptable pathname prefixes */
> static char **ok_paths = NULL;
You didn't update Documentation/git-daemon.txt.
> diff --git a/upload-pack.c b/upload-pack.c
> --- a/upload-pack.c
> +++ b/upload-pack.c
> @@ -4,13 +4,19 @@
> #include "tag.h"
> #include "object.h"
>
> -static const char upload_pack_usage[] = "git-upload-pack <dir>";
> +static const char upload_pack_usage[] = "git-upload-pack [--strict] [--timeout=nn] <dir>";
Ditto.
After being confronted with incomplete documentation again just minutes
ago (will send patch soon), I think I'm going to start to be annoying
and watch patches for this issue specifically. ;-)
--
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: The git protocol and DoS
From: David Brown @ 2005-10-20 0:20 UTC (permalink / raw)
To: Petr Baudis; +Cc: H. Peter Anvin, Git Mailing List
In-Reply-To: <20051019222044.GP30889@pasky.or.cz>
On Thu, Oct 20, 2005 at 12:20:44AM +0200, Petr Baudis wrote:
> 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.
This kind of password authentication has several problems that make it
fairly unpractical. It is prone to easy dictionary attacks for one thing.
It also for a spoofed server to do replays, and the likes. It also
requires the server to store plaintext passwords.
There are other, much better, authentication algorithms, but short of doing
signatures, none are really much more secure. The closest you'll get to
secure remote passwords is SRP <http://srp.stanford.edu/>, which is quite
good, and doesn't even require plaintext passwords to be stored. It might
just be easier at that point to use signatures, though.
Dave
^ permalink raw reply
* Re: git-send-pack segfaulting on DebianPPC
From: Petr Baudis @ 2005-10-20 0:11 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7v8xwpxdef.fsf@assigned-by-dhcp.cox.net>
Dear diary, on Thu, Oct 20, 2005 at 02:03:52AM CEST, I got a letter
where Junio C Hamano <junkio@cox.net> told me that...
> Petr Baudis <pasky@suse.cz> writes:
>
> > Hmm, what bash version are you using? It's enclosed in
> >
> > for tag in *
> >
> > and perhaps your bash misunderstood.
>
> It probably is your cat not quoting $tag, which you just fixed.
> Martin's repo has a conversion from CVS, with bunch of tags
> whose names are like "Foo **INVALID**" (that's whitespace and
> asterisks).
Eww. Well, I pushed out the fix.
BTW (for anyone reading this), in the near future, I would like to do a
complete quoting review of Cogito, since while I'm trying to be careful
now, it wasn't always so, especially early on. Of course, *I* would also
like to do many other things... *hint* *hint* ;-)
--
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-send-pack segfaulting on DebianPPC
From: Junio C Hamano @ 2005-10-20 0:03 UTC (permalink / raw)
To: Petr Baudis; +Cc: git
In-Reply-To: <20051019235208.GR30889@pasky.or.cz>
Petr Baudis <pasky@suse.cz> writes:
> Hmm, what bash version are you using? It's enclosed in
>
> for tag in *
>
> and perhaps your bash misunderstood.
It probably is your cat not quoting $tag, which you just fixed.
Martin's repo has a conversion from CVS, with bunch of tags
whose names are like "Foo **INVALID**" (that's whitespace and
asterisks).
^ permalink raw reply
* Re: git-send-pack segfaulting on DebianPPC (was: Re: cg-clone, tag objects and cg-push/git-push don't play nice)
From: Petr Baudis @ 2005-10-19 23:52 UTC (permalink / raw)
To: Martin Langhoff; +Cc: git
In-Reply-To: <46a038f90510191623k4f1a7267m50d3bbbd6665a2a3@mail.gmail.com>
Dear diary, on Thu, Oct 20, 2005 at 01:23:11AM CEST, I got a letter
where Martin Langhoff <martin.langhoff@gmail.com> told me that...
> Actually, all the tagsrefs have only one line, but something is going
> weird around tagid=$(cat $tag) as $tag ends up containing many
> filenames. So I undid my initial change to "head -n1", and I'm trying
> to fix the loop.
Hmm, what bash version are you using? It's enclosed in
for tag in *
and perhaps your bash misunderstood.
Anyway, this should've been quoted. I've fixed that in my tree, will
push out soon.
--
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-send-pack segfaulting on DebianPPC (was: Re: cg-clone, tag objects and cg-push/git-push don't play nice)
From: Martin Langhoff @ 2005-10-19 23:23 UTC (permalink / raw)
To: Petr Baudis; +Cc: Linus Torvalds, Junio C Hamano, git, Penny @ Catalyst
In-Reply-To: <20051019223743.GQ30889@pasky.or.cz>
On 10/20/05, Petr Baudis <pasky@suse.cz> wrote:
> Dear diary, on Wed, Oct 19, 2005 at 10:56:35PM CEST, I got a letter
> where Martin Langhoff <martin.langhoff@gmail.com> told me that...
> > To recap: repo is slightly broken because cg-fetch has fetched tag
> > objects, but hasn't followed them through to the commit objects they
> > refer to.
>
> That must be leftover of some old fetch, before cg-fetch got fixed wrt.
> this issue.
Yes, I'm trying to figure out if I can fix it...
> > Internally cg-fetch is actually using git-ssh-fetch (I misreported it
> > using git-fetch-pack), which is working correctly. However, cg-fetch
> > attempts to optimize the fetch process, by not calling git-ssh-fetch
> > if it has the tagobj that the ref points to. How those tag objects get
> > there without commits in the first place I don't know. So I've removed
> > the optimization and life is much better.
>
> The "optimization" or something alike needs to be there at least for the
> user interface, so that we can actually say what tags are we
> downloading; besides, there can be a *lot* of tags. But I'm not sure how
> moot will this all be after Cogito moves to the remote peeking (Real
> Soon Now, promise ;-).
>
> > There is a second bug during the tag fetch. Some of the references
> > (created by git-cvsimport) are multiline, and break cg-fetch. It's
> > probably a bug in git-cvsimport, but I'm fixing cg-fetch to use head
> > -n1 instead of cat. I'll deal with git-cvsimport later.
>
> Eek. Did I miss something and are multiline refs meaningful now? If not,
> they are pretty bad and I'd imagine other parts of Cogito would be
> pretty confused about that. I'd call this a corrupted repository,
> tough. Perhaps a check should be added to fsck.
Actually, all the tagsrefs have only one line, but something is going
weird around tagid=$(cat $tag) as $tag ends up containing many
filenames. So I undid my initial change to "head -n1", and I'm trying
to fix the loop.
cheers,
martin
^ 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