Re: [PATCH 1/2] BreakingChanges: announce switch to "reftable" format

[Patrick Steinhardt <ps@pks.im>]

On Wed, Jul 02, 2025 at 10:03:25AM -0700, Junio C Hamano wrote:
> Patrick Steinhardt <ps@pks.im> 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