Derrick Stolee [off-list ref] writes:
On 6/7/2021 8:34 AM, Derrick Stolee via GitGitGadget wrote:
quoted
From: Derrick Stolee <redacted>
...
quoted
+ old_entry = make_transient_cache_entry(
+ entry[0].mode, &entry[0].oid,
+ old_path, /* stage */ 0);
I didn't realize this before I started integrating with
v2.32.0 (which I should have done before submitting v5) that
make_transient_cache_entry() has changed its prototype to
include a memory pool parameter.
Sorry for the trouble---these are usually all known to me for topics
I happened to have picked up in 'seen', since I try to make it a rule
that 'seen' must be a descendant of 'master'.
How can I usefully communicate the conflicts I find out during the
integration cycles to topic owners, I wonder.
Thanks.
On 6/7/2021 9:05 PM, Junio C Hamano wrote:
Derrick Stolee [off-list ref] writes:
quoted
On 6/7/2021 8:34 AM, Derrick Stolee via GitGitGadget wrote:
quoted
From: Derrick Stolee <redacted>
...
quoted
+ old_entry = make_transient_cache_entry(
+ entry[0].mode, &entry[0].oid,
+ old_path, /* stage */ 0);
I didn't realize this before I started integrating with
v2.32.0 (which I should have done before submitting v5) that
make_transient_cache_entry() has changed its prototype to
include a memory pool parameter.
Sorry for the trouble---these are usually all known to me for topics
I happened to have picked up in 'seen', since I try to make it a rule
that 'seen' must be a descendant of 'master'.
How can I usefully communicate the conflicts I find out during the
integration cycles to topic owners, I wonder.
This is my fault for stacking topics. I used a GitGitGadget PR
to target a custom merge of other topics in flight, so my
merges were testing against a static target. When those topics
were merged, I should have updated my PR to point to 'master' or
even 'next'.
Thanks,
-Stolee