On Wed, Jul 02, 2025 at 10:03:25AM -0700, Junio C Hamano wrote:
> Patrick Steinhardt <ps@xxxxxx> writes:
> > diff --git a/setup.c b/setup.c
> > index f93bd6a24a5..3ab0f11fbfd 100644
> > --- a/setup.c
> > +++ b/setup.c
> > @@ -2541,6 +2541,12 @@ static void repository_format_configure(struct repository_format *repo_fmt,
> > repo_fmt->ref_storage_format = ref_format;
> > } else if (cfg.ref_format != REF_STORAGE_FORMAT_UNKNOWN) {
> > repo_fmt->ref_storage_format = cfg.ref_format;
> > + } else {
> > +#ifdef WITH_BREAKING_CHANGES
> > + repo_fmt->ref_storage_format = REF_STORAGE_FORMAT_REFTABLE;
> > +#else
> > + repo_fmt->ref_storage_format = REF_STORAGE_FORMAT_FILES;
> > +#endif
> > }
> > repo_set_ref_storage_format(the_repository, repo_fmt->ref_storage_format);
> > }
>
> That's obvious one. I think the approach taken by brian's SHA-256
> topic would have introduced REF_STORAGE_FORMAT_DEFAULT and did the
> build-time switching between the two in a single conditional
> definition
>
> #ifndef WITH_BREAKING_CHANGES /* 3.0 */
> # define REF_STORAGE_FORMAT_DEFAULT REF_STORAGE_FORMAT_FILES
> #else
> # define REF_STORAGE_FORMAT_DEFAULT REF_STORAGE_FORMAT_REFTABLE
> #endif
>
> somewhere in a header file. Either way would work, but I wonder if
> these breaking-changes definitions are collected together into a
> single header file (say <bc.h>), it may make the transition at 3.0
> version boundary simpler and less error-prone. We can just discard
> selected conditionals into unconditional definition more easily.
> For example if we moved the default flip between SHA-1 and SHA-256,
> i.e.
>
> #ifndef WITH_BREAKING_CHANGES /* 3.0 */
> # define GIT_HASH_DEFAULT GIT_HASH_SHA1
> #else
> # define GIT_HASH_DEFAULT GIT_HASH_SHA256
> #endif
>
> out of hash.h and have it next to the above REF_STORAGE_FORMAT_DEFAULT
> definition, and then in a subsystem specific header file, after
> including <bc.h>, can say
>
> === In hash.h ===
> #include <bc.h>
> #ifndef GIT_HASH_DEFAULT
> # define GIT_HASH_DEFAULT GIT_HASH_SHA256
> #endif
>
> === In refs.h ===
> #include <bc.h>
> #ifndef REF_STORAGE_FORMAT_DEFAULT
> # define REF_STORAGE_FORMAT_DEFAULT REF_STORAGE_FORMAT_REFTABLE
> #endif
>
> If some reason making reftable backend the default when unspecified
> turns out to be a bit premature at 3.0 boundary while the world is
> ready for SHA-256 by default for new repositories, then we can tweak
> that single header file like so:
>
> -#ifndef WITH_BREAKING_CHANGES /* 3.0 */
> +#ifndef WITH_BREAKING_CHANGES /* 4.0? */
> # define REF_STORAGE_FORMAT_DEFAULT REF_STORAGE_FORMAT_FILES
> #else
> # define REF_STORAGE_FORMAT_DEFAULT REF_STORAGE_FORMAT_REFTABLE
> #endif
>
> -#ifndef WITH_BREAKING_CHANGES
> -# define GIT_HASH_DEFAULT GIT_HASH_SHA1
> -#else
> -# define GIT_HASH_DEFAULT GIT_HASH_SHA256
> -#endif
>
> and optionally change the "if default is not set, use 256" in <hash.h>
> to "unconditionally use 256 as the default", but forgetting to do so
> would not break anything, which makes the process less error prone.
>
> By doing something like this, we'll have a single place <bc.h> to
> see what are being planned, and we can "git log that-header-file" to
> see how our thinking has evolved over time. Hopefully w
