Hi Junio, On Tue, 17 Nov 2020, Junio C Hamano wrote: > Jonathan Nieder <jrnieder@xxxxxxxxx> 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
