Re: What's cooking in git.git (Apr 2020, #03; Tue, 28)

[Junio C Hamano <gitster@pobox.com>]

Taylor Blau <me@ttaylorr.com> writes:

>> * tb/commit-graph-split-strategy (2020-04-15) 7 commits
>>  + commit-graph.c: introduce '--[no-]check-oids'
>>  + commit-graph.h: replace 'commit_hex' with 'commits'
>>  + oidset: introduce 'oidset_size'
>>  + builtin/commit-graph.c: introduce split strategy 'replace'
>>  + builtin/commit-graph.c: introduce split strategy 'no-merge'
>>  + builtin/commit-graph.c: support for '--split[=<strategy>]'
>>  + t/helper/test-read-graph.c: support commit-graph chains
>>  (this branch is used by tb/commit-graph-fd-exhaustion-fix.)
>>
>>  "git commit-graph write" learned different ways to write out split
>>  files.
>>
>>  Will merge to 'master'.
> ...
> In either case, the rest of the series is ready to merge, and other
> topics depend on it, so I figure that we can merge the first 6 patches
> and hold off on the last one for now.
>
> Sound good?

If other topics that depend on it build on the whole series, merging
only the first 6 does not make much sense.  These other ones are
blocked forever.

Applying a single patch to revert the no-check-oids patch on top of
this series, and merging the resulting 8-commit series to 'master',
may be a workable solution, though.  We need to keep an eye on the
merge possibly reintroducing the no-check-oids stuff when the
dependent topics are merged to 'master' (that is why we do not want
to see people build new things on another topic that is slushy), but
I think there is only one topic, so it should be manageable.

Why don't we do this:

 $ git checkout tb/commit-graph-fd-exhaustion-fix
 $ git revert tb/commit-graph-split-strategy
 $ git checkout master
 $ git merge tb/commit-graph-fd-exhaustion-fix
 $ git branch -d tb/commit-graph-fd-exhaustion-fix tb/commit-graph-split-strategy

That's the simplest solution and we'll have two fewer topics we need
to worry about when we are done.