Jeff King writes:
> On Tue, May 09, 2017 at 11:48:17AM +0900, Junio C Hamano wrote:
>
>> > I guess what I was asking was: do you still think it was unclear, or do
>> > you think you were just being dense?
>> >
>> > I don't feel like I gave any information in the follow-on
On Mon, May 08, 2017 at 10:54:12PM -0400, Jeff King wrote:
> Contents are the same. I decided to leave the "; do" as it
> matches the rest of the script. If we're going to fix it, we
> should do them all.
Like this, perhaps.
I didn't go on a crusade against "; do" in the other scripts, but
On Tue, May 09, 2017 at 11:48:17AM +0900, Junio C Hamano wrote:
> > I guess what I was asking was: do you still think it was unclear, or do
> > you think you were just being dense?
> >
> > I don't feel like I gave any information in the follow-on explanation
> > that wasn't in the commit message,
Jeff King writes:
> On Tue, May 09, 2017 at 11:14:18AM +0900, Junio C Hamano wrote:
>
>> Jeff King writes:
>>
>> >> Ah, OK, and now I understand why you called this a "bug" (which is
>> >> older and do not need to be addressed as part of 2.13) in the
>> >>
On Tue, May 09, 2017 at 11:14:18AM +0900, Junio C Hamano wrote:
> Jeff King writes:
>
> >> Ah, OK, and now I understand why you called this a "bug" (which is
> >> older and do not need to be addressed as part of 2.13) in the
> >> original message. The new tests check requests
Jeff King writes:
>> Ah, OK, and now I understand why you called this a "bug" (which is
>> older and do not need to be addressed as part of 2.13) in the
>> original message. The new tests check requests that ought to
>> produce an empty packfile as the result actually do, but
On Tue, May 09, 2017 at 09:44:50AM +0900, Junio C Hamano wrote:
> Jeff King writes:
>
> > On Mon, May 08, 2017 at 01:56:27PM +0900, Junio C Hamano wrote:
> >
> >> Surely, even if we need to exclude some objects from an existing
> >> packfile due to these selection options, we
Jeff King writes:
> On Mon, May 08, 2017 at 01:56:27PM +0900, Junio C Hamano wrote:
>
>> Surely, even if we need to exclude some objects from an existing
>> packfile due to these selection options, we should be able to reuse
>> the non-excluded part, no? The end result may
On Mon, May 08, 2017 at 01:56:27PM +0900, Junio C Hamano wrote:
> Jeff King writes:
>
> > If certain options like --honor-pack-keep, --local, or
> > --incremental are used with pack-objects, then we need to
> > feed each potential object to want_object_in_pack() to see
> > if it
Jeff King writes:
> If certain options like --honor-pack-keep, --local, or
> --incremental are used with pack-objects, then we need to
> feed each potential object to want_object_in_pack() to see
> if it should be filtered out. This is totally contrary to
> the purpose of the
If certain options like --honor-pack-keep, --local, or
--incremental are used with pack-objects, then we need to
feed each potential object to want_object_in_pack() to see
if it should be filtered out. This is totally contrary to
the purpose of the pack-reuse optimization, which tries hard
to
11 matches
Mail list logo