Re: [PATCH v4 0/9] Allow overriding the default name of the default branch

[Johannes Schindelin <Johannes.Schindelin@gmx.de>]

Hi Ed,

[re-Cc:ing the list, I hope you don't mind]

On Mon, 13 Jul 2020, Edward Thomson wrote:

> On Mon, Jul 13, 2020 at 8:38 PM Johannes Schindelin
> <Johannes.Schindelin@gmx.de> wrote:
> > On Sun, 12 Jul 2020, Edward Thomson wrote:
> > > One thing that isn't obvious to me, though, is why templates take
> > > precedence over the command-line option.  I would expect the
> > > command-line option to be the highest priority option given, just
> > > like configuration values specified on the command-line override
> > > values from configuration files.
> >
> > Side note: I have not tested this, but I trust you did, and my reading
> > of the code agrees that it does this.
>
> I was speaking about the notion of configuration options specified with
> `-c` on the command line overridding things in configuration files.
> Like how you override `init.templateDir` on the command line:
>
> > The truth is that overriding the default name via editing the templates is
> > just not a very good strategy, it is fraught with peril, as e.g.
> > `init.templateDir` is a thing that can be easily specified via the
> > command-line (`git -c init.templateDir=/tmp/my-templates init`).
>
> I agree that setting a template that contains `HEAD` is perilous.  But
> it's an established and supported bit of peril.  I think that the question
> of configuration specificity is _also_ an established one (and not nearly
> so perilous).  Just like `-cinit.defaultBranch` overrides the global
> configuration, I would expect it to override the templates as well.

Is it really well-established? If so, it might really be worth doing
something like this:

-- snip --
diff --git a/builtin/init-db.c b/builtin/init-db.c
index cee64823cbb..9149f9e51f5 100644
--- a/builtin/init-db.c
+++ b/builtin/init-db.c
@@ -210,7 +210,7 @@ static int create_default_files(const char *template_path,
 	struct strbuf buf = STRBUF_INIT;
 	char *path;
 	char junk[2];
-	int reinit;
+	int reinit, override_HEAD_in_templates = 0;
 	int filemode;
 	struct strbuf err = STRBUF_INIT;

@@ -218,6 +218,12 @@ static int create_default_files(const char *template_path,
 	init_db_template_dir = NULL; /* re-set in case it was set before */
 	git_config(git_init_db_config, NULL);

+	if (initial_branch) {
+		path = git_path_buf(&buf, "HEAD");
+		override_HEAD_in_templates = access(path, R_OK) ||
+			readlink(path, junk, sizeof(junk)-1) < 0;
+	}
+
 	/*
 	 * First copy the templates -- we might have the default
 	 * config file there, in which case we would want to read
@@ -265,7 +271,7 @@ static int create_default_files(const char *template_path,
 	path = git_path_buf(&buf, "HEAD");
 	reinit = (!access(path, R_OK)
 		  || readlink(path, junk, sizeof(junk)-1) != -1);
-	if (!reinit) {
+	if (!reinit || override_HEAD_in_templates) {
 		char *ref;

 		if (!initial_branch)
-- snap --

Note that I initially considered moving the `reinit = [...]` part to before
the `copy_templates()` call, but `reinit` actually does quite a bit more
than just guard the symref creation of `HEAD`: it also guards the
`core.filemode` test, the `core.symlinks` test and the `core.ignoreCase`
test. There _might_ be legitimate use cases to side-step those by
delivering a `HEAD` in the templates (which is, just as setting the
initial branch using templates, a relatively awkward and fragile way to
override it, but hey, we're trying to address exactly such a scenario).

However, even having written the patch (which would still lack a
regression test), I am not 100% certain that we would want to risk
including it in v2.28.0. It strikes me as such a fringe use case (with
relatively obvious ways out) while the patch is not completely risk free
(I _think_ it should be safe, of course, but it touches a relatively
central part of Git).

Ciao,
Dscho