Re: What's cooking in git.git (Feb 2020, #01; Wed, 5)

[Taylor Blau <me@ttaylorr.com>]

Hi Junio,

On Wed, Feb 05, 2020 at 03:31:11PM -0800, Junio C Hamano wrote:
> * tb/commit-graph-object-dir (2020-02-04) 5 commits
>  - commit-graph.h: use odb in 'load_commit_graph_one_fd_st'
>  - commit-graph.c: remove path normalization, comparison
>  - commit-graph.h: store object directory in 'struct commit_graph'
>  - commit-graph.h: store an odb in 'struct write_commit_graph_context'
>  - t5318: don't pass non-object directory to '--object-dir'
>  (this branch is used by tb/commit-graph-split-merge.)
>
>  The code to compute the commit-graph has been taught to use a more
>  robust way to tell if two object directories refer to the same
>  thing.
>
>  Will merge to 'next'.

This topic is ready to go. We've been using this at GitHub for a few
days without any issue, but we weren't users of '--object-dir' to begin
with, so take our usage with a grain of salt, I suppose :-).

> * tb/commit-graph-split-merge (2020-02-05) 3 commits
>  - builtin/commit-graph.c: support '--input=none'
>  - builtin/commit-graph.c: introduce '--input=<source>'
>  - builtin/commit-graph.c: support '--split[=<strategy>]'
>  (this branch uses tb/commit-graph-object-dir.)
>
>  The code to write out the commit-graph has been taught a few
>  options to control if the resulting graph chains should be merged
>  or a single new incremental graph is created.
>
>  Will merge to 'next'?

I think that this is ready. Martin Ågren and I discussed a little bit
about the rationale behind why the new options were chosen over
alternatives, but I think we reached consensus (at least, the thread has
been quiet for a few days after sending 'v2').

So, if you're asking whether or not this is ready to merge to 'next',
I'd say that it is, but I'd like to hear from Martin's thoughts, too.
(For what it's worth, we're *also* running this at GitHub, and without
issue).

Thanks,
Taylor