Re: What's cooking in git.git (Jul 2019, #03; Fri, 12)

Matthew DeVore [off-list ref] writes:

On Fri, Jul 12, 2019 at 02:02:52PM -0700, Junio C Hamano wrote:

quoted

* md/list-objects-filter-combo (2019-06-28) 10 commits
 - list-objects-filter-options: make parser void
 - list-objects-filter-options: clean up use of ALLOC_GROW
 - list-objects-filter-options: allow mult. --filter
 - strbuf: give URL-encoding API a char predicate fn
 - list-objects-filter-options: make filter_spec a string_list
 - list-objects-filter-options: move error check up
 - list-objects-filter: implement composite filters
 - list-objects-filter-options: always supply *errbuf
 - list-objects-filter: put omits set in filter struct
 - list-objects-filter: encapsulate filter components

 The list-objects-filter API (used to create a sparse/lazy clone)
 learned to take a combined filter specification.

 There is a bit of interaction with cc/multi-promisor topic, whose
 conflict resolution I have no confidence in X-<.  Extra sets of
 eyes are appreciated.

Sorry for the delay. I was on vacation and then catching up for a week after I
got back. I uploaded a merged commit here:

https://github.com/matvore/git/tree/filts

And the merged file itself (only this one had conflicts) is here:

https://github.com/matvore/git/blob/filts/list-objects-filter.c

Thanks.  I fetched the 'filts' branch and found:

 (1) master..filts~1 matches the copy I have above exactly (modulo
     my sign-off and committer identity, of course);

 (2) if I merge cc/multi-promisor on top of filts~1 using the machinery
     I use to rebuild 'pu' every day, I get more-or-less the same result
     as your 'filt' branch (modulo formatting and minor comments).

So it does look like the conflict resolution I have been carrying is
something you would agree on, which is a good news ;-)  Thanks.

I'll comment on the conflicts:
...
md/list-objects-filter-combo changed the contract of this function such that an
attempt to combine filter specs will terminate with BUG rather than return an
error. All the callers already check filter_options.choice, so this is still
fine (it particular, I double-checked partial_clone_get_default_filter_spec and
its call site at builtin/fetch.c:1524)

OK, thanks for being careful.

quoted

  	/*
  	 * Record the initial filter-spec in the config as
  	 * the default for subsequent fetches from this remote.
  	 */
++<<<<<<< md/list-objects-filter-combo
 +	core_partial_clone_filter_default =
 +		xstrdup(expand_list_objects_filter_spec(filter_options));
 +	git_config_set("core.partialclonefilter",
 +		       core_partial_clone_filter_default);
++||||||| merged common ancestors
++	core_partial_clone_filter_default =
++		xstrdup(filter_options->filter_spec);
++	git_config_set("core.partialclonefilter",
++		       core_partial_clone_filter_default);
++=======
+ 	filter_name = xstrfmt("remote.%s.partialclonefilter", remote);
+ 	git_config_set(filter_name, filter_options->filter_spec);
+ 	free(filter_name);
+ 
+ 	/* Make sure the config info are reset */
+ 	promisor_remote_reinit();
++>>>>>>> cc/multi-promisor
  }
  
  void partial_clone_get_default_filter_spec(

md/list-objects-filter-combo used the expand_list_objects_filter_spec function
to expand the filter spec string rather than get it directly. So the merged
result simply applies that alteration to cc/multi-promisor.

I checked whether callers to this function (partial_clone_register) would ever
give a null filter_options (or a non-null with a NULL filter_spec) and both
calls are guarded by "if (filter_options.choice)" so filter_options.filter_spec
should also be set.

Good.  This was the part I was most unsure about.

Thanks.