On Wed, Jan 09, 2019 at 02:42:28PM -0800, Stefan Beller wrote:
> On Wed, Jan 9, 2019 at 1:37 PM Stefan Beller wrote:
> >
> > > > Yikes, the conflicts with sb/more-repo-in-api is quite irritating.
> > > > I think I'll postpone the later parts of this series and ask this to
> > > > be sent after sb
On Wed, Jan 9, 2019 at 1:37 PM Stefan Beller wrote:
>
> > > Yikes, the conflicts with sb/more-repo-in-api is quite irritating.
> > > I think I'll postpone the later parts of this series and ask this to
> > > be sent after sb/more-repo-in-api matures a bit mroe.
> >
> > There were several conflicts
> > Yikes, the conflicts with sb/more-repo-in-api is quite irritating.
> > I think I'll postpone the later parts of this series and ask this to
> > be sent after sb/more-repo-in-api matures a bit mroe.
>
> There were several conflicts, but it was mostly just tedious textual
> fixups. I pushed the r
On Tue, Jan 08, 2019 at 10:52:19AM -0800, Junio C Hamano wrote:
> Junio C Hamano writes:
>
> > Jeff King writes:
> >
> >> Yeah, they should. I think one of them will need René's patch, which
> >> changes the body of quick_has_loose(). I can roll it as a separate topic
> >> if that's easier (or
Junio C Hamano writes:
> Jeff King writes:
>
>> Yeah, they should. I think one of them will need René's patch, which
>> changes the body of quick_has_loose(). I can roll it as a separate topic
>> if that's easier (or just wait a week or so until René's cleanups
>> graduate).
>
> Nah, what I got
On 1/8/2019 1:07 PM, Junio C Hamano wrote:
Jeff King writes:
Yeah, they should. I think one of them will need René's patch, which
changes the body of quick_has_loose(). I can roll it as a separate topic
if that's easier (or just wait a week or so until René's cleanups
graduate).
Nah, what I g
Jeff King writes:
> Yeah, they should. I think one of them will need René's patch, which
> changes the body of quick_has_loose(). I can roll it as a separate topic
> if that's easier (or just wait a week or so until René's cleanups
> graduate).
Nah, what I got is already good to work with. Both
and 11
> > conflict with sb/more-repo-in-api; 9 could go in unmodified.
>
> I think these later steps are based on something a lot newer than
> the result of applying your updates to the jk/loose-object-cache
> series they fix. I think I untangled and backported one of the
> e
; I skimmed them; they look good to me. 6 and 8 are particularly
> satisfying; getting rid of hash copy operations just feels nice. :)
>
> Junio only took 1 to 5 into pu; 6, 7 and its sidekick 8, 10 and 11
> conflict with sb/more-repo-in-api; 9 could go in unmodified.
I think these la
Am 07.01.2019 um 09:31 schrieb Jeff King:
> I also cleaned up my sha1/object_id patch and rebased it on top of what
> you have here. Though as I worked on it, it expanded in scope a bit.
> Possibly it should be a separate series entirely, but that would create
> some annoying textual conflicts on m
René Scharfe writes:
> Am 28.12.2018 um 19:04 schrieb Junio C Hamano:
>> * jk/loose-object-cache (2018-11-24) 10 commits
> ...
> So this has hit master in the meantime. We discussed a sort performance
> fix in [1]; I'll reply with a short series containing a cleaned-up a
On Sun, Jan 06, 2019 at 05:39:14PM +0100, René Scharfe wrote:
> Am 28.12.2018 um 19:04 schrieb Junio C Hamano:
> > * jk/loose-object-cache (2018-11-24) 10 commits
> > (merged to 'next' on 2018-12-28 at 5a5faf384e)
> > + odb_load_loose_cache: fix strbuf leak
>
Am 28.12.2018 um 19:04 schrieb Junio C Hamano:
> * jk/loose-object-cache (2018-11-24) 10 commits
> (merged to 'next' on 2018-12-28 at 5a5faf384e)
> + odb_load_loose_cache: fix strbuf leak
> + fetch-pack: drop custom loose object cache
> + sha1-file: use loose object
13 matches
Mail list logo
