"Han-Wen Nienhuys via GitGitGadget" <gitgitgadget@xxxxxxxxx> writes:
> int init_db(const char *git_dir, const char *real_git_dir,
> - const char *template_dir, unsigned int flags)
> + const char *template_dir, const char *ref_storage_format,
> + unsigned int flags)
> {
This change, and Brian's SHA-256 work, obviously will introduce a
conflict as the other side wants to add an extra parameter to choose
from different hash algorhtims.
I wonder if we should rather add a single pointer to a struct that
can hold various initialization options as an extra parameter. That
way, each topic can add and manage its own new member in the struct.
> static int create_default_files(const char *template_path,
> - const char *original_git_dir)
> + const char *original_git_dir,
> + const char *ref_storage_format, int flags)
Pretty much the same story here, too. The other side aims to be
more generic and passes a "struct repository_format *" as an extra
parameter. I think the repository-format structure needs to have
what ref backend is in use, so instead of passing only the string
like this patch, we can use the appropriate member from the struct?
Please try to apply this series to 'master', and try to merge the
result with the tip of 'pu', to see if there are other areas that a
better coordination between you and Brian would help moving these
two topics together and work well with each other.
I am not sure how quickly Brian's SHA-256 work solidifies enough to
build on top of, but if it is a good option to build on top of the
topic, that may save some work from this topic, too, as the
mechanism to choose something (i.e. hash algorithm for Brian's
topic, ref backend for this topic) fundamental to the repository at
runtime and at initialization time needs similar supporting
infrastructure, such as changes in "[12/24] setup: allow
check_repository_format to read repository format", and "[13/24]
builtin/init-db: allow specifying hash algorithm on command line"
of that series.
Thanks.
