Johannes Schindelin <Johannes.Schindelin@xxxxxx> wrote: > On Fri, 11 Oct 2019, Junio C Hamano wrote: > > * ds/sparse-cone (2019-10-08) 17 commits > > - sparse-checkout: cone mode should not interact with .gitignore > > - sparse-checkout: write using lockfile > > - sparse-checkout: update working directory in-process > > - sparse-checkout: sanitize for nested folders > > - read-tree: show progress by default > > - unpack-trees: add progress to clear_ce_flags() > > - unpack-trees: hash less in cone mode > > - sparse-checkout: init and set in cone mode > > - sparse-checkout: use hashmaps for cone patterns > > - sparse-checkout: add 'cone' mode > > - trace2: add region in clear_ce_flags > > - sparse-checkout: create 'disable' subcommand > > - sparse-checkout: add '--stdin' option to set subcommand > > - sparse-checkout: 'set' subcommand > > - clone: add --sparse mode > > - sparse-checkout: create 'init' subcommand > > - sparse-checkout: create builtin with 'list' subcommand > > > > Management of sparsely checked-out working tree has gained a > > dedicated "sparse-checkout" command. > > > > Seems not to play well with the hashmap updates. > > Hrm. I had sent out links to the three fixups needed to make the build > green: > > https://public-inbox.org/git/nycvar.QRO.7.76.6.1910081055210.46@xxxxxxxxxxxxxxxxx/ > > In particular, the patches to squash were: > > https://github.com/git-for-windows/git/commit/f74259754971b427a14e6290681e18950824b99d > https://github.com/git-for-windows/git/commit/124c8bc08e974e76ca7d956dc07eb288e71d639e > https://github.com/git-for-windows/git/commit/45948433d1b48ff513fbd37f134c0f1491c78192 > diff --git a/dir.c b/dir.c > index 0135f9e2180..9efcdc9aacd 100644 > --- a/dir.c > +++ b/dir.c <snip> > @@ -706,8 +710,8 @@ static void add_pattern_to_hashsets(struct pattern_list *pl, struct path_pattern > > clear_hashmaps: > warning(_("disabling cone pattern matching")); > - hashmap_free(&pl->parent_hashmap, 1); > - hashmap_free(&pl->recursive_hashmap, 1); > + hashmap_free(&pl->parent_hashmap); > + hashmap_free(&pl->recursive_hashmap); I just took a brief look, but that appears to leak memory. "hashmap_free(var, 1)" should be replaced with "hashmap_free_entries(var, struct foo, member)" Only "hashmap_free(var, 0)" can become "hashmap_free(var)"
