Taylor Blau <me@xxxxxxxxxxxx> 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.
