On Mon, Jul 01, 2019 at 12:02:45PM -0500, Taylor Blau wrote:
> One thing that I didn't catch in my initial review that I am seeing now
> is the ".alternate" marker. Why did you choose this? I was thinking that
> ".have" would make more sense since it's consistent with what's shown in
> the ref adv
Hi Peff,
On Mon, Jul 01, 2019 at 09:17:13AM -0400, Jeff King wrote:
> On Mon, Jul 01, 2019 at 08:59:45AM -0400, Jeff King wrote:
>
> > Yes, this is weakening the ties of the feature to the transport code.
> > Traditionally transport-oriented code was the only user, but it also
> > used the upload-
On Mon, Jul 01, 2019 at 08:59:45AM -0400, Jeff King wrote:
> Yes, this is weakening the ties of the feature to the transport code.
> Traditionally transport-oriented code was the only user, but it also
> used the upload-pack transport under the hood to access the alternate
> (that was changed a wh
On Mon, Jul 01, 2019 at 08:25:09AM -0400, Derrick Stolee wrote:
> > I'm not sure what you have in mind, exactly. If you are asking whether
> > there are more places that alternate refs could be used, I can't think
> > of any. If you are asking whether this is in the wrong place, no, I
> > think it
On 6/29/2019 3:55 AM, Jeff King wrote:
> On Fri, Jun 28, 2019 at 09:22:56AM -0700, Junio C Hamano wrote:
>
>>> argv_array_push(&rev_list.args, "--quiet");
>>> + argv_array_push(&rev_list.args, "--alternate-refs");
>>> if (opt->progress)
>>> argv_array_pushf(&rev_list.args, "-
On 6/29/2019 3:43 AM, Jeff King wrote:
> On Fri, Jun 28, 2019 at 08:51:04AM -0400, Derrick Stolee wrote:
>
>> On 6/28/2019 6:11 AM, Jeff King wrote:
>>> When we receive a remote ref update to sha1 "X", we want to check that
>>> we have all of the objects needed by "X". We can assume that our
>>> r
On Fri, Jun 28, 2019 at 09:22:56AM -0700, Junio C Hamano wrote:
> > argv_array_push(&rev_list.args, "--quiet");
> > + argv_array_push(&rev_list.args, "--alternate-refs");
> > if (opt->progress)
> > argv_array_pushf(&rev_list.args, "--progress=%s",
> >
On Fri, Jun 28, 2019 at 08:51:04AM -0400, Derrick Stolee wrote:
> On 6/28/2019 6:11 AM, Jeff King wrote:
> > When we receive a remote ref update to sha1 "X", we want to check that
> > we have all of the objects needed by "X". We can assume that our
> > repository is not currently corrupted, and th
Jeff King writes:
> When we receive a remote ref update to sha1 "X", we want to check that
> we have all of the objects needed by "X". We can assume that our
> repository is not currently corrupted, and therefore if we have a ref
> pointing at "Y", we have all of its objects. So we can stop our
>
On 6/28/2019 6:11 AM, Jeff King wrote:
> When we receive a remote ref update to sha1 "X", we want to check that
> we have all of the objects needed by "X". We can assume that our
> repository is not currently corrupted, and therefore if we have a ref
> pointing at "Y", we have all of its objects. S
On Fri, Jun 28, 2019 at 06:11:31AM -0400, Jeff King wrote:
> Subject: [PATCH] check_everything_connected: assume alternate ref tips...
Heh. This subject should just be "check_connected" these days. I wrote
this patch originally many years ago, before 7043c7071c
(check_everything_connected: use a
When we receive a remote ref update to sha1 "X", we want to check that
we have all of the objects needed by "X". We can assume that our
repository is not currently corrupted, and therefore if we have a ref
pointing at "Y", we have all of its objects. So we can stop our
traversal from "X" as soon as
12 matches
Mail list logo
