Ævar Arnfjörð Bjarmason <avarab@xxxxxxxxx> writes:
> diff --git a/GIT-VERSION-GEN b/GIT-VERSION-GEN
> index 4f94fc7574..c76bbedf86 100755
> --- a/GIT-VERSION-GEN
> +++ b/GIT-VERSION-GEN
> @@ -37,4 +37,5 @@ fi
> test "$VN" = "$VC" || {
> echo >&2 "GIT_VERSION = $VN"
> echo "GIT_VERSION = $VN" >$GVF
> + echo "GIT_VERSION_INT = $(echo $VN | sed -e 's/^\([0-9]*\)\.\([0-9]*\)\..*/\1\2/')" >>$GVF
> }
Unlike Perl's v1.2.3.4 notation, this forces us worry when we go
from v2.99.0 to v2.100.0 and eventually to v3.0, no?
> + } else if (1) {
> + /*
> + * TODO: Instead of `if 1` we should check a
> + * core.version variable here.
> + *
> + * I.e. if set to core.version=2.13 the user is opting
> + * in to get deprecations set at dep_at right away,
> + * and also perhaps experimental features from a
> + * sister experimental() interface.
> + */
This essentially forces us to always read _some_ configuration.
Some commands are meant to work outside repositories, so those who
want to affect them needs to write core.version in their global
configuration. Some low-level plumbing commands may want to do
absolute minimum without configurablity.
I am not saying that it is absolutely a bad design decision to force
us to read some configuration (yet); it's just that it is something
that we have to keep in mind and always think about the
ramifications of.
> + die(_("Early bird deprecation error: %s"), message);
> + }
> +}