Re: [PATCH 00/28] Use main as default branch name

From: Johannes Schindelin <johannes.schindelin@gmx.de>
Date: Nov 18, 2020, 11:32 UTC
Message-ID: <nycvar.QRO.7.76.6.2011181207220.56@tvgsbejvaqbjf.bet>
In-Reply-To: <xmqqima343vb.fsf@gitster.c.googlers.com>

Hi Junio,

On Tue, 17 Nov 2020, Junio C Hamano wrote:

Show 18 quoted lines

> Jonathan Nieder <jrnieder@gmail.com> writes:
>
> >> IMHO, though, all of this is orthogonal to question of what the default
> >> is. Unless we are thinking the basename thing would work as a default,
> >> but I don't think that resolves any of the backwards-compatibility
> >> concerns.
> >
> > If we think it would make sense as the *eventual* default, we could use
> >
> > 	[init]
> > 		defaultBranchName =
> >
> > (i.e., an empty string) to request it early.
>
> I am not opposed to the idea to invent a notation that asks for the
> basename behaviour, but I do not think it is a good idea to use "an
> empty string" for that.  I'd rather see us use some consistent
> naming convention to denote any new "non-constant string" thing.

At least in the tests, using the empty string for `GIT_TEST_DEFAULT_INITIAL_BRANCH_NAME` is equivalent for not setting it at all, i.e. to trigger the fall-back.

So yes, I totally agree that triggering an interactive prompt by the empty value is not really a good idea (nor a particularly intuitive behavior).

With your idea to special-case any value starting with a colon, `:ask:` seems like a saner approach.

Having said that, I would still favor the fall-back `main` over this idea: it is a much smaller (and less annoying) change of behavior to use a less loaded name than to change from a previously non-interactive to a now-interactive operation.

As to using the base name by default: I don't think that is a good idea at all. Not only doesn't it work when you run `git init` in the root directory (which some people do, and that's totally okay with me), it also does not work with any base name that isn't a valid ref name. Try this at home:

	$ git check-ref-format --branch "My Documents"
	fatal: 'My Documents' is not a valid branch name

So while it is a cute idea, in general it will simply fail, and is therefore worse than any alternative that does _not_ fail in general.

Show 10 quoted lines

> What Peff suggested is a more viable possibility, for example.  When
> "[init] defaultBranchAlgorithm = <name>" is set, the fixed string
> "init.defaultBranch" is ignored and the algorithm specified with its
> name is invoked to come up with a name dynamically.  We may start
> with something like 'dirname' as the only supported algorithm but
> that way we would avoid painting ourselves in a corner out of which
> we cannot escape (e.g. we may come up with a better way than the
> basename thing, and we would not have a good way to give it a name
> that is easy to use if we wasted "an empty string" for the basename
> thing).

Indeed. In the spirit of minimizing disruption (as promised in https://sfconservancy.org/news/2020/jun/23/gitbranchname/), I would like to stay away from changing the default behavior _that_ much.

My current plan is to implement a warning in `git init` (much like the `pull.rebase` one, which I thought would raise outcries of frustration, but to my surprise this did not happen, and `git init` is _a lot_ less common than `git pull`).

This needs to be done with care, obviously. I haven't looked yet, but I think there is a chance that `git clone` would implicitly look at `init.defaultBranch` only to override it later by the name of the remote primary branch. In that case, we obviously do not want to warn the user because the `init.defaultBranch` value is not actually used.

Ciao, Dscho