On Tue, Feb 02 2021, Jonathan Tan wrote: >> > I really don't care much, but this really needs a corresponding >> > documentation update. I.e. something like: >> > >> > init.defaultBranch:: >> > Allows overriding the default branch name e.g. when initializing a >> > new repository or when cloning an empty repository. >> > >> > When cloning a repository over protocol v2 (i.e. ssh://, https://, >> > file://, but not a /some/path), and if that repository has >> > init.defaultBranch configured, the server will advertise its >> > preferred default branch name, and we'll take its configuration over >> > ours. >> >> Thanks - I'll use some of your wording, but I think it's best to leave >> open the possibility that cloning using protocol v0 or the disk clone >> (/some/path) copies over the current HEAD as well. > > Looking back on this, I think that it's natural to think that both an > empty repository and a non-empty one have a HEAD that points somewhere, > and "git clone" would behave the same way in both cases. So I'll hold > off on the documentation change. You mean for a v6 it'll do the same thing in the local clone case too and thus we won't need to document the exception? Sounds good. I was mainly pointing out the need to document the current divergent behavior. Documenting that something isn't consistent shouldn't be seen as a blessing that the divergence is a good idea, it's an aid to our users so they can understand why their git version does X when they might be expecting Y.
