On Tue, Aug 21, 2018 at 01:57:07PM -0700, Junio C Hamano wrote:
> Jeff King writes:
>
> > Ah, yeah, I think you're right. We call find_patch_start(), which thinks
> > the "---" line is the end of the commit message. That makes sense when
> > parsing trailers out of "format-patch" output, but
On Tue, Aug 21, 2018 at 01:52:33PM -0700, Junio C Hamano wrote:
> > I think there really are two bugs here, though. The find_patch_start()
> > check is overly lax, but we also should not have to use it at all when
> > we know there is no patch.
>
> Yes, I was grepping for callchains, and it
Jeff King writes:
> Ah, yeah, I think you're right. We call find_patch_start(), which thinks
> the "---" line is the end of the commit message. That makes sense when
> parsing trailers out of "format-patch" output, but not when we know we
> have just the commit message.
Yes, but that does not
Jeff King writes:
> Another is to tighten the check. Something like this seems more
> sensible:
Great minds think alike; is it a space was exactly what I was toying
with before I went to lunch. FWIW I saw the full test suite passes
when I came back and then saw you had an identical patch ;-)
On Tue, Aug 21, 2018 at 04:07:47PM -0400, Jeff King wrote:
> On Tue, Aug 21, 2018 at 12:50:09PM -0700, Junio C Hamano wrote:
>
> > > Sorry for commenting on something completely off-topic, but when
> > > applied with "git am -s", I get a resulting commit with 3 S-o-b (the
> > > above two, plus
On Tue, Aug 21, 2018 at 12:50:09PM -0700, Junio C Hamano wrote:
> > Sorry for commenting on something completely off-topic, but when
> > applied with "git am -s", I get a resulting commit with 3 S-o-b (the
> > above two, plus the one added by "-s"), with a blank line in between
> > them. I can
On Tue, Aug 21, 2018 at 12:43:49PM -0700, Junio C Hamano wrote:
> Jeff King writes:
>
> > When we serve a fetch, we pass the "wants" and "haves" from
> > ...
> > This lets us limit the change primarily to the oe_delta()
> > and oe_set_delta_ext() functions. And as a bonus, most of
> > the rest
Junio C Hamano writes:
> Jeff King writes:
>
>> When we serve a fetch, we pass the "wants" and "haves" from
>> ...
>> This lets us limit the change primarily to the oe_delta()
>> and oe_set_delta_ext() functions. And as a bonus, most of
>> the rest of the code does not consider these dummy
Jeff King writes:
> When we serve a fetch, we pass the "wants" and "haves" from
> ...
> This lets us limit the change primarily to the oe_delta()
> and oe_set_delta_ext() functions. And as a bonus, most of
> the rest of the code does not consider these dummy entries
> at all, saving both runtime
When we serve a fetch, we pass the "wants" and "haves" from
the fetch negotiation to pack-objects. That tells us not
only which objects we need to send, but we also use the
boundary commits as "preferred bases": their trees and blobs
are candidates for delta bases, both for reusing on-disk
deltas
On Mon, Aug 20, 2018 at 02:03:53PM -0700, Junio C Hamano wrote:
> > So taking all of those options into account, what I ended up
> > with is a separate list of "external bases" that are not
> > part of the main packing list. Each delta entry that points
> > to an external base has a single-bit
Jeff King writes:
> And that's exactly what this patch does: when we're
> considering whether to reuse an on-disk delta, if bitmaps
> tell us the other side has the object (and we're making a
> thin-pack), then we reuse it.
That's really the natural extension and logical consequence of the
On Fri, Aug 17, 2018 at 03:57:18PM -0700, Stefan Beller wrote:
> On Fri, Aug 17, 2018 at 2:06 PM Jeff King wrote:
> >
> > When we serve a fetch, we pass the "wants" and "haves" from
> > the fetch negotiation to pack-objects. That tells us not
> > only which objects we need to send, but we also
On Fri, Aug 17, 2018 at 2:06 PM Jeff King wrote:
>
> When we serve a fetch, we pass the "wants" and "haves" from
> the fetch negotiation to pack-objects. That tells us not
> only which objects we need to send, but we also use the
> boundary commits as "preferred bases": their trees and blobs
>
When we serve a fetch, we pass the "wants" and "haves" from
the fetch negotiation to pack-objects. That tells us not
only which objects we need to send, but we also use the
boundary commits as "preferred bases": their trees and blobs
are candidates for delta bases, both for reusing on-disk
deltas
15 matches
Mail list logo
