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

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

Hi Junio,

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

> 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.

> 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