From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on inbox.vuxu.org X-Spam-Level: X-Spam-Status: No, score=-0.1 required=5.0 tests=DKIM_SIGNED,DKIM_VALID, DKIM_VALID_AU autolearn=ham autolearn_force=no version=3.4.4 Received: (qmail 32581 invoked from network); 19 Apr 2022 19:33:18 -0000 Received: from 9front.inri.net (168.235.81.73) by inbox.vuxu.org with ESMTPUTF8; 19 Apr 2022 19:33:18 -0000 Received: from mail-ej1-f43.google.com ([209.85.218.43]) by 9front; Tue Apr 19 15:31:38 -0400 2022 Received: by mail-ej1-f43.google.com with SMTP id lc2so34927960ejb.12 for <9front@9front.org>; Tue, 19 Apr 2022 12:31:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mforney.org; s=google; h=mime-version:in-reply-to:references:from:date:message-id:subject:to; bh=GqHa6t6LonK1JUDzAR2qFreHHwMT6Y+QwBrtGLob700=; b=boQcZMApjtE/K3idYlhqV+F9VlFnMkb81g3bAlbwjVQnl1lUwWvjIA5Di80O3Td037 VB3R/38s8K6Vtwrsw+W4F6RaEUYqoPe/l/UmWHYAbDqNNsScLyBePH/Rx/mHlme+keau 9nLG50LD+5SOOn7KJcfhRZH42cUDe+fH4Bm+H1TABRlKuR6O9pY+IGH+iWe8hqKwCqdB o5Fgmc5KgugCDSsCTCKAe/AaH9mxNyKp8IOULBouYfM4tLw3wJn7z3pSLuZzDGdKhvsg JKuDulSsXntYpuwTB9MZlIVS5deG8vLLMOPT6MWkokALpSXwDIfajJwCg+h8te3aTauj k8aQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to; bh=GqHa6t6LonK1JUDzAR2qFreHHwMT6Y+QwBrtGLob700=; b=HPbwZOiw2TD7ZPmNemenjywBTIAaBjg2I6BWO/YWxODuyn8wcrKBiDR3n5vq35dRyX WHTHvbmWOakrUL7Z7QGg0+90F2Me0J+phRdJrpzC6x+OPrd5Vr3aq2vJojl1J4uoJ9Fj 5JYHawWHQNz5HCMagMOMyUQzAx7PQ3y9CVEFcgmzq4ww0A3Lijjf+u3DNwxlzO5gBVWD fqB6402qQsDjEqPJWomcGUuHdypVqN2bipQs+TXRE+JHmt+cXiE8ywxi+mMFCMYxqIDk r7zZZrhwtcelxo3l9lXRNiyqk5u5JHdm8natyQWawN1Iw8Y36Li8ru27tboF+lD60qos E5Gw== X-Gm-Message-State: AOAM531wq7jvVpQCmaiGIc6hoN1eXbS2AmfurLKVZa1YxgMXWPFRflED J8/GsCOt9kO1+2d/lkG0Isnqi+HA93StPFCQ1RkH2iP9KwdZEQ== X-Google-Smtp-Source: ABdhPJwFfLAWtk5RcnTfSM2jNSQqfzVPVb6JG1RrR2MIpcsUyq5jeU5cYVJrdsILwu1DznNJimy/8Jx/aTy7R8Wbi7A= X-Received: by 2002:a17:907:2ce3:b0:6ef:eadf:443b with SMTP id hz3-20020a1709072ce300b006efeadf443bmr3077360ejc.288.1650396693316; Tue, 19 Apr 2022 12:31:33 -0700 (PDT) MIME-Version: 1.0 Received: by 2002:a05:6f02:5a4:b0:19:6590:b591 with HTTP; Tue, 19 Apr 2022 12:31:31 -0700 (PDT) X-Originating-IP: [98.45.152.168] In-Reply-To: <404C9B5CFE08FE9146154E6D8964C191@eigenstate.org> References: <6E68ADE1468D00715CFB8A660CA41558@eigenstate.org> <404C9B5CFE08FE9146154E6D8964C191@eigenstate.org> From: Michael Forney Date: Tue, 19 Apr 2022 12:31:31 -0700 Message-ID: To: 9front@9front.org Content-Type: text/plain; charset="UTF-8" List-ID: <9front.9front.org> List-Help: X-Glyph: ➈ X-Bullshit: pipelining standard injection controller Subject: Re: [9front] git/pull: fetch all branches (please test) Reply-To: 9front@9front.org Precedence: bulk On 2022-04-11, ori@eigenstate.org wrote: > diff 1d9d4ffef89e883949261ec9c56c57e0344726d7 uncommitted > --- a/sys/src/cmd/git/fetch.c > +++ b/sys/src/cmd/git/fetch.c > @@ -180,12 +180,13 @@ > int > fetchpack(Conn *c) > { > - char buf[Pktmax], *sp[3]; > + char buf[Pktmax], *sp[3], *ep; > char *packtmp, *idxtmp, **ref; > Hash h, *have, *want; > int nref, refsz, first; > - int i, n, req, pfd; > + int i, n, l, req, pfd; > vlong packsz; > + Objset hadobj; > Object *o; > > nref = 0; > @@ -246,13 +247,19 @@ > req = 1; > } > flushpkt(c); > + osinit(&hadobj); > for(i = 0; i < nref; i++){ > - if(hasheq(&have[i], &Zhash)) > + if(hasheq(&have[i], &Zhash) || oshas(&hadobj, have[i])) > continue; > + if((o = readobject(have[i])) == nil) > + sysfatal("missing object we should have: %H", have[i]); > + osadd(&hadobj, o); > + unref(o); > n = snprint(buf, sizeof(buf), "have %H\n", have[i]); > if(writepkt(c, buf, n + 1) == -1) > sysfatal("could not send have for %H", have[i]); > } > + osclear(&hadobj); I've been looking over the http-protocol docs, and it describes an algorithm involving a priority queue and commit graph traversal that we don't seem to do. How does this work when our refs have several local commits that the server doesn't have? > if(!req) > flushpkt(c); > > @@ -260,7 +267,7 @@ > if(writepkt(c, buf, n) == -1) > sysfatal("write: %r"); > if(!req) > - return 0; > + goto showrefs; > if(readphase(c) == -1) > sysfatal("read: %r"); > if((n = readpkt(c, buf, sizeof(buf))) == -1) > @@ -277,7 +284,28 @@ > sysfatal("could not create %s: %r", packtmp); > > fprint(2, "fetching...\n"); > - packsz = 0; > + /* > + * Work around torvalds git bug: we get duplicate have lines Do you mean duplicate ACK lines? From my reading of the protocol docs, "have" lines are only sent by us (the client). In fact, I don't really see much about ACK lines at all. Do you know if this is described anywhere in the git docs? > + * somtimes, even though the protocol is supposed to start the Typo here. > + * pack file immediately. > + * > + * Skip ahead until we read 'PACK' off the wire > + */ > + while(1){ > + if(readn(c->rfd, buf, 4) != 4) > + sysfatal("fetch packfile: short read"); > + buf[4] = 0; > + if(strncmp(buf, "PACK", 4) == 0) > + break; > + l = strtol(buf, &ep, 16); > + if(l == 0 || ep != buf + 4) > + sysfatal("fetch packfile: junk pktline"); > + if(readn(c->rfd, buf, l) != l) > + sysfatal("fetch packfile: short read"); > + } > + if(write(pfd, "PACK", 4) != 4) > + sysfatal("write pack header: %r"); > + packsz = 4; > while(1){ > n = read(c->rfd, buf, sizeof buf); > if(n == 0) > --- a/sys/src/cmd/git/pull > +++ b/sys/src/cmd/git/pull > @@ -7,13 +7,10 @@ > upstream=$2 > url=$3 > dir=$4 > - bflag=() > dflag=() > - if(! ~ $#branch 0) > - bflag=(-b $branch) > if(! ~ $#debug 0) > dflag='-d' > - {git/fetch $dflag $bflag -u $upstream $url >[2=3] || die $status} | awk ' > + {git/fetch $dflag -u $upstream $url >[2=3] || die $status} | awk ' > /^remote/{ > if($2=="HEAD") > next Now that $branch is unused, I think you can remove the corresponding positional parameter in the update function, as well as the git/pull -a and -b options.