Allow overriding the default name of the default branch #656

gitgitgadget · 2020-06-16T13:23:43Z

On the Git mailing list, Jeff King wrote (reply to this):

On Mon, Jun 15, 2020 at 12:50:13PM +0000, Johannes Schindelin via GitGitGadget wrote: > diff --git a/builtin/clone.c b/builtin/clone.c > index 487b0a42d75..755fcaeb0ba 100644 > --- a/builtin/clone.c > +++ b/builtin/clone.c > @@ -718,6 +718,7 @@ static void update_head(const struct ref *our, const struct ref *remote, > /* Local default branch link */ > if (create_symref("HEAD", our->name, NULL) < 0) > die(_("unable to update HEAD")); > + git_config_set("core.mainbranch", head); > if (!option_bare) { > update_ref(msg, "HEAD", &our->old_oid, NULL, 0, > UPDATE_REFS_DIE_ON_ERR); Just making sure I understand what's going on here... This covers the case that we've run "clone -b foo" or similar, but there are two other case arms when "foo" is a tag, or the remote HEAD is unreachable. And there we don't set core.mainbranch at all. But we would not want it to be missing, because that will likely need to stay a default for "master" indefinitely (to keep behavior for existing repositories). However, it won't be missing. We'll always have set it during the init_db() call, and this is just overriding that. So we'd end update_head() with either: - core.mainbranch set to the same branch we point HEAD to, whether we got it from the remote side or from "-b foo" - if we write a detached HEAD, then core.mainbranch remains at init.mainbranch (or defaulting to "master" now, and probably "main" later). We have no better option. If so, then that makes sense to me. -Peff

On the Git mailing list, Johannes Schindelin wrote (reply to this):

Hi Peff, On Tue, 16 Jun 2020, Jeff King wrote: > On Mon, Jun 15, 2020 at 12:50:13PM +0000, Johannes Schindelin via GitGitGadget wrote: > > > diff --git a/builtin/clone.c b/builtin/clone.c > > index 487b0a42d75..755fcaeb0ba 100644 > > --- a/builtin/clone.c > > +++ b/builtin/clone.c > > @@ -718,6 +718,7 @@ static void update_head(const struct ref *our, const struct ref *remote, > > /* Local default branch link */ > > if (create_symref("HEAD", our->name, NULL) < 0) > > die(_("unable to update HEAD")); > > + git_config_set("core.mainbranch", head); > > if (!option_bare) { > > update_ref(msg, "HEAD", &our->old_oid, NULL, 0, > > UPDATE_REFS_DIE_ON_ERR); > > Just making sure I understand what's going on here... > > This covers the case that we've run "clone -b foo" or similar, but there > are two other case arms when "foo" is a tag, or the remote HEAD is > unreachable. And there we don't set core.mainbranch at all. It was actually meant to catch the case where the remote repository has a default branch other than `master`. > But we would not want it to be missing, because that will likely need to > stay a default for "master" indefinitely (to keep behavior for existing > repositories). However, it won't be missing. We'll always have set it > during the init_db() call, and this is just overriding that. So we'd end > update_head() with either: > > - core.mainbranch set to the same branch we point HEAD to, whether we > got it from the remote side or from "-b foo" > > - if we write a detached HEAD, then core.mainbranch remains at > init.mainbranch (or defaulting to "master" now, and probably "main" > later). We have no better option. > > If so, then that makes sense to me. In any case, this does not matter anymore, as I am dropping `core.mainBranch` from v3, as you had suggested elsewhere in this thread. Ciao, Dscho

gitgitgadget · 2020-06-24T01:08:06Z

On the Git mailing list, Junio C Hamano wrote (reply to this):

"Don Goodman-Wilson via GitGitGadget" <gitgitgadget@gmail.com> writes: > diff --git a/builtin/init-db.c b/builtin/init-db.c > index a898153901..b8634b5f35 100644 > --- a/builtin/init-db.c > +++ b/builtin/init-db.c > @@ -269,7 +269,7 @@ static int create_default_files(const char *template_path, > char *ref; > > if (!initial_branch) > - initial_branch = "master"; > + initial_branch = git_default_branch_name(); > > ref = xstrfmt("refs/heads/%s", initial_branch); > if (check_refname_format(ref, 0) < 0) Continuing with the division of labor between this helper and its caller, I had this funny dislike of falling back here and not in the caller. But with the same idea of using "reinit", we could get rid of this "if the caller didn't give us initial_branch, fall back to..." logic from the function. The caller may do reinit = create_default_files(... initial_branch ? initial_branch : "master", ...); if (reinit || initial_branch) warning(_(...)); in the previous step and then we can teach the caller to use the configured value instead of the hardcoded "master". That's much better ;-) Other than that, looks good to me. Thanks.

On the Git mailing list, Johannes Schindelin wrote (reply to this):

Hi Junio, On Tue, 23 Jun 2020, Junio C Hamano wrote: > "Don Goodman-Wilson via GitGitGadget" <gitgitgadget@gmail.com> > writes: > > > diff --git a/builtin/init-db.c b/builtin/init-db.c > > index a898153901..b8634b5f35 100644 > > --- a/builtin/init-db.c > > +++ b/builtin/init-db.c > > @@ -269,7 +269,7 @@ static int create_default_files(const char *template_path, > > char *ref; > > > > if (!initial_branch) > > - initial_branch = "master"; > > + initial_branch = git_default_branch_name(); > > > > ref = xstrfmt("refs/heads/%s", initial_branch); > > if (check_refname_format(ref, 0) < 0) > > Continuing with the division of labor between this helper and its > caller, I had this funny dislike of falling back here and not in the > caller. But with the same idea of using "reinit", we could get rid > of this "if the caller didn't give us initial_branch, fall back > to..." logic from the function. The caller may do > > reinit = create_default_files(... > initial_branch ? initial_branch : "master", > ...); > if (reinit || initial_branch) > warning(_(...)); > > in the previous step and then we can teach the caller to use the > configured value instead of the hardcoded "master". While that is really tempting, there is another called of `init_db()` (which calls `create_default_files()`): `builtin/clone.c`. And I do not wish to duplicate the logic there. So I left this as-is. Ciao, Dscho > > That's much better ;-) > > Other than that, looks good to me. > > Thanks. >

On the Git mailing list, Junio C Hamano wrote (reply to this):

Johannes Schindelin <Johannes.Schindelin@gmx.de> writes: >> reinit = create_default_files(... >> initial_branch ? initial_branch : "master", >> ...); >> if (reinit || initial_branch) >> warning(_(...)); >> >> in the previous step and then we can teach the caller to use the >> configured value instead of the hardcoded "master". > > While that is really tempting, there is another called of `init_db()` > (which calls `create_default_files()`): `builtin/clone.c`. And I do not > wish to duplicate the logic there. > > So I left this as-is. I am still on the fence after seeing v4, but let's leave it as is. The reason why I wanted to leave the "default to" logic out of the helper was to make sure it implements little or no policy, which would leave the door open to let other callers of the helper to use their own and different default, but we can revisit when we acquire the third caller. I do not see an immediate need to make the clone's fallback default configurable separately from what init uses for the default initial branch name, and with modern servers it is doubtful that the fallback default by clone is ever used anyway. Thanks.

gitgitgadget · 2020-06-24T01:02:04Z

On the Git mailing list, Junio C Hamano wrote (reply to this):

"Johannes Schindelin via GitGitGadget" <gitgitgadget@gmail.com> writes: > [verse] > 'git init' [-q | --quiet] [--bare] [--template=<template_directory>] > [--separate-git-dir <git dir>] [--object-format=<format] Completely offtopic. We lack the closing ket> here. > + [-b <branch-name> | --initial-branch=<branch-name>] > [--shared[=<permissions>]] [directory] > > > @@ -67,6 +68,12 @@ repository. > + > If this is reinitialization, the repository will be moved to the specified path. > > +-b <branch-name:: > +--initial-branch=<branch-name>:: > + > +Use the specified name for the initial branch in the newly created repository. > +If not specified, fall back to the default name: `master`. OK. > diff --git a/builtin/clone.c b/builtin/clone.c > index 2a8e3aaaed..b751bdf13e 100644 > --- a/builtin/clone.c > +++ b/builtin/clone.c > @@ -1111,7 +1111,8 @@ int cmd_clone(int argc, const char **argv, const char *prefix) > } > } > > - init_db(git_dir, real_git_dir, option_template, GIT_HASH_UNKNOWN, INIT_DB_QUIET); > + init_db(git_dir, real_git_dir, option_template, GIT_HASH_UNKNOWN, NULL, > + INIT_DB_QUIET); > > if (real_git_dir) > git_dir = real_git_dir; > diff --git a/builtin/init-db.c b/builtin/init-db.c > index 0b7222e718..a898153901 100644 > --- a/builtin/init-db.c > +++ b/builtin/init-db.c > @@ -203,6 +203,7 @@ void initialize_repository_version(int hash_algo) > > static int create_default_files(const char *template_path, > const char *original_git_dir, > + const char *initial_branch, > const struct repository_format *fmt) > { > struct stat st1; > @@ -258,16 +259,29 @@ static int create_default_files(const char *template_path, > die("failed to set up refs db: %s", err.buf); > > /* > - * Create the default symlink from ".git/HEAD" to the "master" > - * branch, if it does not exist yet. > + * Create the default symlink from ".git/HEAD" to the default > + * branch name, if it does not exist yet. > */ To the caller of this helper, it may be "the default", but as far as this helper is concerned, it is not "default" but the initial branch that was given by the caller. How about... /* * Point the initial branch with HEAD symref, if HEAD does * not exist yet. */ ... to modernize the reference to symlink and replace it with symref? > + if (!initial_branch) > + initial_branch = "master"; > + > + ref = xstrfmt("refs/heads/%s", initial_branch); > + if (check_refname_format(ref, 0) < 0) > + die(_("invalid initial branch name: '%s'"), > + initial_branch); Good. We make sure to prefix with "refs/heads/" so the callers cannot abuse us to point HEAD outside the local branches. > + if (create_symref("HEAD", ref, NULL) < 0) > exit(1); > - } > + free(ref); > + } else if (initial_branch) > + warning(_("re-init: ignoring --initial-branch=%s"), > + initial_branch); Somehow the error checking convention feels uneven in this API. It is a warning-worthy offense for the caller to give initial_branch when we are re-initializing, but it is not an error for the caller not to supply the initial branch name on the other side of if/else. Worse yet, this helper function even knows the command line option name that resulted in the parameter coming to it. That unevenness ultimately comes from the fact that the caller does not know if we are dealing with a repository that already has HEAD before calling, but at least we should be able to tell the caller if we initialized or not with our return value and allow the caller to issue this warning---that way we can lose the warning from here and get rid of the uneven feeling. Oh, and ... > @@ -383,7 +397,8 @@ static void validate_hash_algorithm(struct repository_format *repo_fmt, int hash > } > > int init_db(const char *git_dir, const char *real_git_dir, > - const char *template_dir, int hash, unsigned int flags) > + const char *template_dir, int hash, const char *initial_branch, > + unsigned int flags) > { > int reinit; > int exist_ok = flags & INIT_DB_EXIST_OK; > @@ -425,7 +440,8 @@ int init_db(const char *git_dir, const char *real_git_dir, > > validate_hash_algorithm(&repo_fmt, hash); > > - reinit = create_default_files(template_dir, original_git_dir, &repo_fmt); > + reinit = create_default_files(template_dir, original_git_dir, > + initial_branch, &repo_fmt); ... we are telling the caller if we are in reinit situation, so we can afford to do exactly that. reinit = create_default_files... if (reinit && initial_branch) warning(_("re-init: ignored --initial-branch")); That's much better ;-) Other than that, looks good to me. Thanks.

On the Git mailing list, Johannes Schindelin wrote (reply to this):

Hi Junio, On Tue, 23 Jun 2020, Junio C Hamano wrote: > "Johannes Schindelin via GitGitGadget" <gitgitgadget@gmail.com> > writes: > > > [verse] > > 'git init' [-q | --quiet] [--bare] [--template=<template_directory>] > > [--separate-git-dir <git dir>] [--object-format=<format] > > Completely offtopic. We lack the closing ket> here. Not so off-topic: the fix for this would cause conflicts. In the interest of avoiding merge conflicts, I incorporated a patch to fix that (`git grep` found two more instances, which I fixed "while at it"). > > + [-b <branch-name> | --initial-branch=<branch-name>] > > [--shared[=<permissions>]] [directory] > > > > > > @@ -67,6 +68,12 @@ repository. > > + > > If this is reinitialization, the repository will be moved to the specified path. > > > > +-b <branch-name:: > > +--initial-branch=<branch-name>:: > > + > > +Use the specified name for the initial branch in the newly created repository. > > +If not specified, fall back to the default name: `master`. > > OK. > > > diff --git a/builtin/clone.c b/builtin/clone.c > > index 2a8e3aaaed..b751bdf13e 100644 > > --- a/builtin/clone.c > > +++ b/builtin/clone.c > > @@ -1111,7 +1111,8 @@ int cmd_clone(int argc, const char **argv, const char *prefix) > > } > > } > > > > - init_db(git_dir, real_git_dir, option_template, GIT_HASH_UNKNOWN, INIT_DB_QUIET); > > + init_db(git_dir, real_git_dir, option_template, GIT_HASH_UNKNOWN, NULL, > > + INIT_DB_QUIET); > > > > if (real_git_dir) > > git_dir = real_git_dir; > > diff --git a/builtin/init-db.c b/builtin/init-db.c > > index 0b7222e718..a898153901 100644 > > --- a/builtin/init-db.c > > +++ b/builtin/init-db.c > > @@ -203,6 +203,7 @@ void initialize_repository_version(int hash_algo) > > > > static int create_default_files(const char *template_path, > > const char *original_git_dir, > > + const char *initial_branch, > > const struct repository_format *fmt) > > { > > struct stat st1; > > @@ -258,16 +259,29 @@ static int create_default_files(const char *template_path, > > die("failed to set up refs db: %s", err.buf); > > > > /* > > - * Create the default symlink from ".git/HEAD" to the "master" > > - * branch, if it does not exist yet. > > + * Create the default symlink from ".git/HEAD" to the default > > + * branch name, if it does not exist yet. > > */ > > To the caller of this helper, it may be "the default", but as far as > this helper is concerned, it is not "default" but the initial branch > that was given by the caller. How about... > > /* > * Point the initial branch with HEAD symref, if HEAD does > * not exist yet. > */ > > ... to modernize the reference to symlink and replace it with > symref? Good point. I massaged your proposed comment and replaced the old one with it. > > + if (!initial_branch) > > + initial_branch = "master"; > > + > > + ref = xstrfmt("refs/heads/%s", initial_branch); > > + if (check_refname_format(ref, 0) < 0) > > + die(_("invalid initial branch name: '%s'"), > > + initial_branch); > > Good. We make sure to prefix with "refs/heads/" so the callers > cannot abuse us to point HEAD outside the local branches. Yes, Peff offered that concern, and I agree. > > + if (create_symref("HEAD", ref, NULL) < 0) > > exit(1); > > - } > > + free(ref); > > + } else if (initial_branch) > > + warning(_("re-init: ignoring --initial-branch=%s"), > > + initial_branch); > > Somehow the error checking convention feels uneven in this API. It > is a warning-worthy offense for the caller to give initial_branch > when we are re-initializing, but it is not an error for the caller > not to supply the initial branch name on the other side of if/else. > Worse yet, this helper function even knows the command line option > name that resulted in the parameter coming to it. > > That unevenness ultimately comes from the fact that the caller does > not know if we are dealing with a repository that already has HEAD > before calling, but at least we should be able to tell the caller > if we initialized or not with our return value and allow the caller > to issue this warning---that way we can lose the warning from here > and get rid of the uneven feeling. Oh, and ... > > > @@ -383,7 +397,8 @@ static void validate_hash_algorithm(struct repository_format *repo_fmt, int hash > > } > > > > int init_db(const char *git_dir, const char *real_git_dir, > > - const char *template_dir, int hash, unsigned int flags) > > + const char *template_dir, int hash, const char *initial_branch, > > + unsigned int flags) > > { > > int reinit; > > int exist_ok = flags & INIT_DB_EXIST_OK; > > @@ -425,7 +440,8 @@ int init_db(const char *git_dir, const char *real_git_dir, > > > > validate_hash_algorithm(&repo_fmt, hash); > > > > - reinit = create_default_files(template_dir, original_git_dir, &repo_fmt); > > + reinit = create_default_files(template_dir, original_git_dir, > > + initial_branch, &repo_fmt); > > ... we are telling the caller if we are in reinit situation, so we > can afford to do exactly that. > > reinit = create_default_files... > if (reinit && initial_branch) > warning(_("re-init: ignored --initial-branch")); I changed it accordingly. Thanks, Dscho > > That's much better ;-) > > Other than that, looks good to me. > > Thanks. > >

gitgitgadget · 2020-06-24T16:18:23Z

On the Git mailing list, Junio C Hamano wrote (reply to this):

"Johannes Schindelin via GitGitGadget" <gitgitgadget@gmail.com> writes: > Even so, it should be okay to fix this behavior without anything like a > longer transition period: > > - The `git submodule update --remote` command is not really common. > > - Current Git's behavior when running this command is outright > confusing, unless the remote repository's current branch _is_ `master` > (in which case the proposed behavior matches the old behavior). > > - If a user encounters a regression due to the changed behavior, the fix > is actually trivial: setting `submodule.<name>.branch` to `master` > will reinstate the old behavior. > > Helped-by: Philippe Blain <levraiphilippeblain@gmail.com> > Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> > --- Well explained. Thanks.

gitgitgadget · 2020-06-24T02:20:12Z

On the Git mailing list, Philippe Blain wrote (reply to this):

Hi Dscho, > Le 23 juin 2020 à 18:33, Johannes Schindelin via GitGitGadget <gitgitgadget@gmail.com> a écrit : > > From: Johannes Schindelin <johannes.schindelin@gmx.de> > > When `remote.<name>.branch` is not configured, `git submodule update` > currently falls back to using the branch name `master`. A much better > idea, however, is to use `HEAD`: on all Git servers running reasonably > recent Git versions, the symref `HEAD` points to the main branch. To be pedantic, it is up to the maintainer/developers to make sure that HEAD on the canonic repository indeed points to the branch that is considered the 'main' branch of the project; the Git version does not really matter IMO... I've seen plenty of repos at work that have HEAD pointing to `master` but `master` is not used, or not anymore... > Note: t7419 demonstrates that there _might_ be use cases out there that > _expect_ `git submodule update --remote` to update submodules to the > remote `master` branch even if the remote `HEAD` points to another > branch. Arguably, this patch makes the behavior more intuitive, but > there is a slight possibility that this might cause regressions in > obscure setups. > > Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> I think that's an excellent idea. However I'd be more explicit in the commit message title: submodule: fall back to remote's HEAD for missing remote.<name>.branch meta comment: I never know where is the best place to make suggestions about changing the commit message title, since I can't quote it in my replies! > --- > Documentation/git-submodule.txt | 4 ++-- > builtin/submodule--helper.c | 2 +- > t/t7406-submodule-update.sh | 16 ++++++++++++++++ > t/t7419-submodule-set-branch.sh | 7 +++++-- > 4 files changed, 24 insertions(+), 5 deletions(-) I think Documentation/gitmodules.txt (`submodule.<name>.branch` header) should also be changed to reflect the behaviour change: diff --git a/Documentation/gitmodules.txt b/Documentation/gitmodules.txt index 67275fd187..539b4e1997 100644 --- a/Documentation/gitmodules.txt +++ b/Documentation/gitmodules.txt @@ -49,9 +49,9 @@ submodule.<name>.update:: submodule.<name>.branch:: A remote branch name for tracking updates in the upstream submodule. - If the option is not specified, it defaults to 'master'. A special - value of `.` is used to indicate that the name of the branch in the - submodule should be the same name as the current branch in the + If the option is not specified, it defaults to the remote 'HEAD'. + A special value of `.` is used to indicate that the name of the branch + in the submodule should be the same name as the current branch in the current repository. See the `--remote` documentation in linkgit:git-submodule[1] for details. > diff --git a/Documentation/git-submodule.txt b/Documentation/git-submodule.txt > index c9ed2bf3d5..b20f85e622 100644 > --- a/Documentation/git-submodule.txt > +++ b/Documentation/git-submodule.txt > @@ -284,7 +284,7 @@ OPTIONS > `.gitmodules` for `update --remote`. A special value of `.` is used to > indicate that the name of the branch in the submodule should be the > same name as the current branch in the current repository. If the > - option is not specified, it defaults to 'master'. > + option is not specified, it defaults to 'HEAD'. Just to be extra clear (it's easy to get confused with submodules!) I'd say explicitly: If the option is not specified, it defaults to the remote 'HEAD'. > > -f:: > --force:: > @@ -322,7 +322,7 @@ OPTIONS > the superproject's recorded SHA-1 to update the submodule, use the > status of the submodule's remote-tracking branch. The remote used > is branch's remote (`branch.<name>.remote`), defaulting to `origin`. > - The remote branch used defaults to `master`, but the branch name may > + The remote branch used defaults to `HEAD`, but the branch name may Same thing here: The remote branch used defaults to the remote `HEAD`. > be overridden by setting the `submodule.<name>.branch` option in > either `.gitmodules` or `.git/config` (with `.git/config` taking > precedence). Also, you seem to have missed the `master` reference in the description of the 'set-branch' subcommand. Something like this would do, I think: diff --git a/Documentation/git-submodule.txt b/Documentation/git-submodule.txt index c9ed2bf3d5..8cf5831a72 100644 --- a/Documentation/git-submodule.txt +++ b/Documentation/git-submodule.txt @@ -183,7 +183,7 @@ set-branch (-d|--default) [--] <path>:: Sets the default remote tracking branch for the submodule. The `--branch` option allows the remote branch to be specified. The `--default` option removes the submodule.<name>.branch configuration - key, which causes the tracking branch to default to 'master'. + key, which causes the tracking branch to default to the remote 'HEAD'. set-url [--] <path> <newurl>:: Sets the URL of the specified submodule to <newurl>. Then, it will The rest of the patch looks good. Cheers, Philippe.

On the Git mailing list, Johannes Schindelin wrote (reply to this):

This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. --8323328-1232997827-1593003071=:54 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hi Philippe, On Tue, 23 Jun 2020, Philippe Blain wrote: > > Le 23 juin 2020 =C3=A0 18:33, Johannes Schindelin via GitGitGadget <gi= tgitgadget@gmail.com> a =C3=A9crit : > > > > From: Johannes Schindelin <johannes.schindelin@gmx.de> > > > > When `remote.<name>.branch` is not configured, `git submodule update` > > currently falls back to using the branch name `master`. A much better > > idea, however, is to use `HEAD`: on all Git servers running reasonably > > recent Git versions, the symref `HEAD` points to the main branch. > > To be pedantic, it is up to the maintainer/developers to make sure that > HEAD on the canonic repository indeed points to the branch that is > considered the 'main' branch of the project; the Git version does not > really matter IMO... I've seen plenty of repos at work that have HEAD > pointing to `master` but `master` is not used, or not anymore... Oh, but in this case, my main concern was servers that are so old that `HEAD` is not a symref, in which case it can be a bit tricky to figure out the default branch. In any case, I feel this is such a minor point that I don't really want to spend a lot of time on this paragraph. > > Note: t7419 demonstrates that there _might_ be use cases out there tha= t > > _expect_ `git submodule update --remote` to update submodules to the > > remote `master` branch even if the remote `HEAD` points to another > > branch. Arguably, this patch makes the behavior more intuitive, but > > there is a slight possibility that this might cause regressions in > > obscure setups. > > > > Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> > > I think that's an excellent idea. However I'd be more explicit in the > commit message title: > > submodule: fall back to remote's HEAD for missing remote.<name>.branch Great! > meta comment: I never know where is the best place to make suggestions > about changing the commit message title, since I can't quote it in my > replies! True. You could copy it, but that's not the same. > > --- > > Documentation/git-submodule.txt | 4 ++-- > > builtin/submodule--helper.c | 2 +- > > t/t7406-submodule-update.sh | 16 ++++++++++++++++ > > t/t7419-submodule-set-branch.sh | 7 +++++-- > > 4 files changed, 24 insertions(+), 5 deletions(-) > > I think Documentation/gitmodules.txt (`submodule.<name>.branch` header) > should also be changed to reflect the behaviour change: > > diff --git a/Documentation/gitmodules.txt b/Documentation/gitmodules.txt > index 67275fd187..539b4e1997 100644 > --- a/Documentation/gitmodules.txt > +++ b/Documentation/gitmodules.txt > @@ -49,9 +49,9 @@ submodule.<name>.update:: > > submodule.<name>.branch:: > A remote branch name for tracking updates in the upstream submodule. > - If the option is not specified, it defaults to 'master'. A special > - value of `.` is used to indicate that the name of the branch in the > - submodule should be the same name as the current branch in the > + If the option is not specified, it defaults to the remote 'HEAD'. > + A special value of `.` is used to indicate that the name of the branch > + in the submodule should be the same name as the current branch in the > current repository. See the `--remote` documentation in > linkgit:git-submodule[1] for details. Excellent, I used that verbatim. Thank you! > > diff --git a/Documentation/git-submodule.txt b/Documentation/git-submo= dule.txt > > index c9ed2bf3d5..b20f85e622 100644 > > --- a/Documentation/git-submodule.txt > > +++ b/Documentation/git-submodule.txt > > @@ -284,7 +284,7 @@ OPTIONS > > `.gitmodules` for `update --remote`. A special value of `.` is used = to > > indicate that the name of the branch in the submodule should be the > > same name as the current branch in the current repository. If the > > - option is not specified, it defaults to 'master'. > > + option is not specified, it defaults to 'HEAD'. > > Just to be extra clear (it's easy to get confused with submodules!) I'd > say explicitly: > > If the option is not specified, it defaults to the remote 'HEAD'. Good idea. I incorporated that, too. > > -f:: > > --force:: > > @@ -322,7 +322,7 @@ OPTIONS > > the superproject's recorded SHA-1 to update the submodule, use the > > status of the submodule's remote-tracking branch. The remote used > > is branch's remote (`branch.<name>.remote`), defaulting to `origin`. > > - The remote branch used defaults to `master`, but the branch name may > > + The remote branch used defaults to `HEAD`, but the branch name may > > Same thing here: > > The remote branch used defaults to the remote `HEAD`. And that. > > be overridden by setting the `submodule.<name>.branch` option in > > either `.gitmodules` or `.git/config` (with `.git/config` taking > > precedence). > > Also, you seem to have missed the `master` reference in the description = of > the 'set-branch' subcommand. Something like this would do, I think: > > diff --git a/Documentation/git-submodule.txt b/Documentation/git-submodu= le.txt > index c9ed2bf3d5..8cf5831a72 100644 > --- a/Documentation/git-submodule.txt > +++ b/Documentation/git-submodule.txt > @@ -183,7 +183,7 @@ set-branch (-d|--default) [--] <path>:: > Sets the default remote tracking branch for the submodule. The > `--branch` option allows the remote branch to be specified. The > `--default` option removes the submodule.<name>.branch configuration > - key, which causes the tracking branch to default to 'master'. > + key, which causes the tracking branch to default to the remote 'HEAD'. > > set-url [--] <path> <newurl>:: > Sets the URL of the specified submodule to <newurl>. Then, it will And that. > The rest of the patch looks good. Awesome. Thank you for helping me improve this patch series! Ciao, Dscho --8323328-1232997827-1593003071=:54--

gitgitgadget · 2020-06-10T23:02:12Z

On the Git mailing list, Junio C Hamano wrote (reply to this):

"Johannes Schindelin via GitGitGadget" <gitgitgadget@gmail.com> writes: > @@ -1263,9 +1263,17 @@ int cmd_clone(int argc, const char **argv, const char *prefix) > remote_head_points_at = NULL; > remote_head = NULL; > option_no_checkout = 1; > - if (!option_bare) > - install_branch_config(0, "master", option_origin, > - "refs/heads/master"); > + if (!option_bare) { > + char *default_branch = git_default_branch_name(0); > + const char *nick; > + > + if (!skip_prefix(default_branch, "refs/heads/", &nick)) > + BUG("unexpected default branch '%s'", > + default_branch); > + install_branch_config(0, nick, option_origin, > + default_branch); > + free(default_branch); > + } Good catch. Normal clone would follow whatever primary branch the other side uses by pointing at it with its "HEAD" but this codepath to deal with a clone of an empty repository needs to use a default, so this is an appropriate change. > write_refspec_config(src_ref_prefix, our_head_points_at, > diff --git a/t/t5609-clone-branch.sh b/t/t5609-clone-branch.sh > index 6e7a7be0522..66af3ac2669 100755 > --- a/t/t5609-clone-branch.sh > +++ b/t/t5609-clone-branch.sh > @@ -67,4 +67,13 @@ test_expect_success 'clone -b not allowed with empty repos' ' > test_must_fail git clone -b branch empty clone-branch-empty > ' > > +test_expect_success 'chooses correct default branch name' ' > + GIT_TEST_DEFAULT_BRANCH_NAME= \ > + git -c core.defaultBranchName=up clone empty whats-up && > + test_write_lines refs/heads/up refs/heads/up >expect && > + git -C whats-up symbolic-ref HEAD >actual && > + git -C whats-up config branch.up.merge >>actual && > + test_cmp expect actual > +' > + > test_done

gitgitgadget · 2020-06-10T23:26:17Z

On the Git mailing list, "brian m. carlson" wrote (reply to this):

--+Yg8W10oK6rlW0RR Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On 2020-06-10 at 21:19:22, Don Goodman-Wilson via GitGitGadget wrote: > + /* prepend "refs/heads/" to the branch name */ > + prefixed =3D xstrfmt("refs/heads/%s", branch_name); > + if (check_refname_format(prefixed, 0)) > + die(_("invalid default branch name: '%s'"), branch_name); I'm glad to see this part and a check for it in the test below. We wouldn't want a typo to create a broken branch name. > +test_expect_success 'invalid custom default branch name' ' > + test_must_fail env GIT_TEST_DEFAULT_BRANCH_NAME=3D"with space" \ > + git init custom-invalid 2>err && > + test_i18ngrep "invalid default branch name" err > +' > + --=20 brian m. carlson: Houston, Texas, US OpenPGP: https://keybase.io/bk2204 --+Yg8W10oK6rlW0RR Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.2.20 (GNU/Linux) iHUEABYKAB0WIQQILOaKnbxl+4PRw5F8DEliiIeigQUCXuFrRQAKCRB8DEliiIei gWh3AQC72M5zaVgqd44QK6VjjLfyxiVHSfnOOSyV3a/g+9EozgD+M7TTfdk7K5r8 OLAKBjiij42iFmjcqHG06qijbKVKpg4= =KA2m -----END PGP SIGNATURE----- --+Yg8W10oK6rlW0RR--

gitgitgadget · 2020-06-11T00:17:27Z

On the Git mailing list, Eric Sunshine wrote (reply to this):

On Wed, Jun 10, 2020 at 5:19 PM Don Goodman-Wilson via GitGitGadget <gitgitgadget@gmail.com> wrote: > [...] > To make this process much less cumbersome, let's introduce support for > `core.defaultBranchName`. That way, users won't need to keep their > copied template files up to date, and won't interfere with default hooks > installed by their administrators. > [...] > Signed-off-by: Don Goodman-Wilson <don@goodman-wilson.com> > --- > diff --git a/refs.c b/refs.c > @@ -560,6 +560,40 @@ void expand_ref_prefix(struct argv_array *prefixes, const char *prefix) > + die(_("Could not retrieve `core.defaultBranchName`")); Nit: here the error message is capitalized... > + if (from_config) > + branch_name = from_config; > + else > + branch_name = "master"; Non-actionable nit: could be written: branch_name = from_config ? from_config : "master"; > + } > + > + if (short_name) > + return from_config ? from_config : xstrdup(branch_name); The logic overall is a bit difficult to follow when trying to understand when and when not to duplicate the string and when and when not to free(), but seems to be correct. > + /* prepend "refs/heads/" to the branch name */ > + prefixed = xstrfmt("refs/heads/%s", branch_name); > + if (check_refname_format(prefixed, 0)) > + die(_("invalid default branch name: '%s'"), branch_name); Here, the error message is not capitalized. It would be nice for both messages to share a common capitalization scheme. These days, we tend to favor _not_ capitalizing error messages, so perhaps remove capitalization from the earlier one. > +/* > + * Retrieves the name of the default branch. If `short_name` is non-zero, the > + * branch name will be prefixed with "refs/heads/". > + */ > +char *git_default_branch_name(int short_name); Overall, the internal logic regarding duplicating/freeing strings would probably be easier to grok if there were two separate functions: char *git_default_branch_name(void); char *git_default_ref_name(void); but that's subjective.

On the Git mailing list, Johannes Schindelin wrote (reply to this):

Hi Eric, On Wed, 10 Jun 2020, Eric Sunshine wrote: > On Wed, Jun 10, 2020 at 5:19 PM Don Goodman-Wilson via GitGitGadget > <gitgitgadget@gmail.com> wrote: > > [...] > > To make this process much less cumbersome, let's introduce support for > > `core.defaultBranchName`. That way, users won't need to keep their > > copied template files up to date, and won't interfere with default hooks > > installed by their administrators. > > [...] > > Signed-off-by: Don Goodman-Wilson <don@goodman-wilson.com> > > --- > > diff --git a/refs.c b/refs.c > > @@ -560,6 +560,40 @@ void expand_ref_prefix(struct argv_array *prefixes, const char *prefix) > > + die(_("Could not retrieve `core.defaultBranchName`")); > > Nit: here the error message is capitalized... I downcased it... > > + if (from_config) > > + branch_name = from_config; > > + else > > + branch_name = "master"; > > Non-actionable nit: could be written: > > branch_name = from_config ? from_config : "master"; Good call. > > + } > > + > > + if (short_name) > > + return from_config ? from_config : xstrdup(branch_name); > > The logic overall is a bit difficult to follow when trying to > understand when and when not to duplicate the string and when and when > not to free(), but seems to be correct. I agree that it is a bit hard to follow, but then, the function is really short, so I hoped it is okay. > > + /* prepend "refs/heads/" to the branch name */ > > + prefixed = xstrfmt("refs/heads/%s", branch_name); > > + if (check_refname_format(prefixed, 0)) > > + die(_("invalid default branch name: '%s'"), branch_name); > > Here, the error message is not capitalized. It would be nice for both > messages to share a common capitalization scheme. These days, we tend > to favor _not_ capitalizing error messages, so perhaps remove > capitalization from the earlier one. > > > +/* > > + * Retrieves the name of the default branch. If `short_name` is non-zero, the > > + * branch name will be prefixed with "refs/heads/". > > + */ > > +char *git_default_branch_name(int short_name); > > Overall, the internal logic regarding duplicating/freeing strings > would probably be easier to grok if there were two separate functions: > > char *git_default_branch_name(void); > char *git_default_ref_name(void); > > but that's subjective. For such a tiny nuance, I'd rather keep it as one function... Thank you, Dscho

On the Git mailing list, Junio C Hamano wrote (reply to this):

Johannes Schindelin <Johannes.Schindelin@gmx.de> writes: >> Overall, the internal logic regarding duplicating/freeing strings >> would probably be easier to grok if there were two separate functions: >> >> char *git_default_branch_name(void); >> char *git_default_ref_name(void); >> >> but that's subjective. > > For such a tiny nuance, I'd rather keep it as one function... And you'd need two functions, default and primary, possibly full and short. Splitting these into two here would mean you'd need four.

On the Git mailing list, Jeff King wrote (reply to this):

On Wed, Jun 10, 2020 at 08:16:38PM -0400, Eric Sunshine wrote: > > +/* > > + * Retrieves the name of the default branch. If `short_name` is non-zero, the > > + * branch name will be prefixed with "refs/heads/". > > + */ > > +char *git_default_branch_name(int short_name); > > Overall, the internal logic regarding duplicating/freeing strings > would probably be easier to grok if there were two separate functions: > > char *git_default_branch_name(void); > char *git_default_ref_name(void); > > but that's subjective. Having seen one of the callers, might it be worth avoiding handing off ownership of the string entirely? I.e., this comes from a string that's already owned for the lifetime of the process (either the environment, or a string stored by the config machinery). Could we just pass that back (or if we want to be more careful about getenv() lifetimes, we can copy it into a static owned by this function)? Then all of the callers can stop dealing with the extra free(), and you can do: const char *git_default_branch_name(void) { return skip_prefix("refs/heads/", git_default_ref_name()); } -Peff

On the Git mailing list, Jeff King wrote (reply to this):

On Tue, Jun 16, 2020 at 08:45:02AM -0400, Jeff King wrote: > On Wed, Jun 10, 2020 at 08:16:38PM -0400, Eric Sunshine wrote: > > > > +/* > > > + * Retrieves the name of the default branch. If `short_name` is non-zero, the > > > + * branch name will be prefixed with "refs/heads/". > > > + */ > > > +char *git_default_branch_name(int short_name); > > > > Overall, the internal logic regarding duplicating/freeing strings > > would probably be easier to grok if there were two separate functions: > > > > char *git_default_branch_name(void); > > char *git_default_ref_name(void); > > > > but that's subjective. > > Having seen one of the callers, might it be worth avoiding handing off > ownership of the string entirely? > > I.e., this comes from a string that's already owned for the lifetime of > the process (either the environment, or a string stored by the config > machinery). Could we just pass that back (or if we want to be more > careful about getenv() lifetimes, we can copy it into a static owned by > this function)? > > Then all of the callers can stop dealing with the extra free(), and you > can do: > > const char *git_default_branch_name(void) > { > return skip_prefix("refs/heads/", git_default_ref_name()); > } Actually, one small hiccup is that the config option specifies the branch name, not the ref name. So you really would have to prepare a static-owned copy of it to turn "foo" into "refs/heads/foo" to get the refname. On the other hand, that would also be a good time to run check_ref_format(). In the patch as-is, the "short" return does not check that the branch is a valid name. -Peff

On the Git mailing list, Johannes Schindelin wrote (reply to this):

Hi Peff, On Tue, 16 Jun 2020, Jeff King wrote: > On Tue, Jun 16, 2020 at 08:45:02AM -0400, Jeff King wrote: > > > On Wed, Jun 10, 2020 at 08:16:38PM -0400, Eric Sunshine wrote: > > > > > > +/* > > > > + * Retrieves the name of the default branch. If `short_name` is non-zero, the > > > > + * branch name will be prefixed with "refs/heads/". > > > > + */ > > > > +char *git_default_branch_name(int short_name); > > > > > > Overall, the internal logic regarding duplicating/freeing strings > > > would probably be easier to grok if there were two separate functions: > > > > > > char *git_default_branch_name(void); > > > char *git_default_ref_name(void); > > > > > > but that's subjective. > > > > Having seen one of the callers, might it be worth avoiding handing off > > ownership of the string entirely? > > > > I.e., this comes from a string that's already owned for the lifetime of > > the process (either the environment, or a string stored by the config > > machinery). Could we just pass that back (or if we want to be more > > careful about getenv() lifetimes, we can copy it into a static owned by > > this function)? > > > > Then all of the callers can stop dealing with the extra free(), and you > > can do: > > > > const char *git_default_branch_name(void) > > { > > return skip_prefix("refs/heads/", git_default_ref_name()); > > } > > Actually, one small hiccup is that the config option specifies the > branch name, not the ref name. So you really would have to prepare a > static-owned copy of it to turn "foo" into "refs/heads/foo" to get the > refname. > > On the other hand, that would also be a good time to run > check_ref_format(). In the patch as-is, the "short" return does not > check that the branch is a valid name. Legit. I will work on this. Thanks, Dscho

On the Git mailing list, Johannes Schindelin wrote (reply to this):

Hi Peff, On Tue, 16 Jun 2020, Jeff King wrote: > On Wed, Jun 10, 2020 at 08:16:38PM -0400, Eric Sunshine wrote: > > > > +/* > > > + * Retrieves the name of the default branch. If `short_name` is non-zero, the > > > + * branch name will be prefixed with "refs/heads/". > > > + */ > > > +char *git_default_branch_name(int short_name); > > > > Overall, the internal logic regarding duplicating/freeing strings > > would probably be easier to grok if there were two separate functions: > > > > char *git_default_branch_name(void); > > char *git_default_ref_name(void); > > > > but that's subjective. > > Having seen one of the callers, might it be worth avoiding handing off > ownership of the string entirely? For `git_default_branch_name()`: yes. For `repo_default_branch_name()`, not really, as that is potentially repository-specific. (Side note: while I cannot really think of a use case where you would want to set `init.defaultBranch` in a repository-local config, there _might_ be use cases for that out there, and it _is_ how our config machinery works.) > I.e., this comes from a string that's already owned for the lifetime of > the process (either the environment, or a string stored by the config > machinery). Could we just pass that back (or if we want to be more > careful about getenv() lifetimes, we can copy it into a static owned by > this function)? > > Then all of the callers can stop dealing with the extra free(), and you > can do: > > const char *git_default_branch_name(void) > { > return skip_prefix("refs/heads/", git_default_ref_name()); > } For ease of use, I decided to only ever return the branch name (but check the full ref). Those callers that actually need the full ref usually also need the branch name, and it is easy enough to call `xstrfmt("refs/heads/%s", ...)`. It might make the code a bit less efficient (but who cares, it's not like we're setting up a gazillion repositories per second all the time), but quite a bit easier to reason about. Ciao, Dscho

gitgitgadget · 2020-06-11T09:38:58Z

On the Git mailing list, Phillip Wood wrote (reply to this):

On 10/06/2020 22:19, Don Goodman-Wilson via GitGitGadget wrote: > From: Don Goodman-Wilson <don@goodman-wilson.com> > > There is a growing number of projects trying to avoid the non-inclusive > name `master` in their repositories. I think it would be helpful to explain why 'master' is no-inclusive even if it originates from the concept of a master copy. i.e. it suggests master/slave even if git is not based on that concept. Have you got some examples of projects that have changed and the names that they are using? I think it would be helpful if we can agree on a replacement for master - if every repository uses a different name for its main branch it adds an extra complication for new contributors to those projects. For existing repositories, this > requires manual work. For new repositories, the only way to do that > automatically is by copying all of Git's template directory, then > hard-coding the desired default branch name into the `.git/HEAD` file, > and then configuring `init.templateDir` to point to those copied > template files. > > To make this process much less cumbersome, let's introduce support for > `core.defaultBranchName`. That way, users won't need to keep their > copied template files up to date, and won't interfere with default hooks > installed by their administrators. > > While at it, also let users set the default branch name via the > environment variable `GIT_TEST_DEFAULT_BRANCH_NAME`, I'm not sure we usually promote the use of GIT_TEST_... environment variables outside of the test suite. > in preparation for > adjusting Git's test suite to a more inclusive default branch name. As > is common in Git, the `GIT_TEST_*` variable takes precedence over the > config setting. > > Note: we use the prefix `core.` instead of `init.` because we want to > adjust also `git clone`, `git fmt-merge-msg` and other commands over the > course of the next commits to respect this setting. > > Helped-by: Johannes Schindelin <johannes.schindelin@gmx.de> > Helped-by: Derrick Stolee <dstolee@microsoft.com> > Signed-off-by: Don Goodman-Wilson <don@goodman-wilson.com> > --- > builtin/init-db.c | 8 +++++--- > refs.c | 34 ++++++++++++++++++++++++++++++++++ > refs.h | 6 ++++++ > t/t0001-init.sh | 20 ++++++++++++++++++++ > 4 files changed, 65 insertions(+), 3 deletions(-) > > diff --git a/builtin/init-db.c b/builtin/init-db.c > index 0b7222e7188..99792adfd43 100644 > --- a/builtin/init-db.c > +++ b/builtin/init-db.c > @@ -258,15 +258,17 @@ static int create_default_files(const char *template_path, > die("failed to set up refs db: %s", err.buf); > > /* > - * Create the default symlink from ".git/HEAD" to the "master" > - * branch, if it does not exist yet. > + * Create the default symlink from ".git/HEAD" to the default > + * branch name, if it does not exist yet. > */ > path = git_path_buf(&buf, "HEAD"); > reinit = (!access(path, R_OK) > || readlink(path, junk, sizeof(junk)-1) != -1); > if (!reinit) { > - if (create_symref("HEAD", "refs/heads/master", NULL) < 0) > + char *default_ref = git_default_branch_name(0); > + if (create_symref("HEAD", default_ref, NULL) < 0) > exit(1); > + free(default_ref); > } > > initialize_repository_version(fmt->hash_algo); > diff --git a/refs.c b/refs.c > index 224ff66c7bb..8499b3865cb 100644 > --- a/refs.c > +++ b/refs.c > @@ -560,6 +560,40 @@ void expand_ref_prefix(struct argv_array *prefixes, const char *prefix) > argv_array_pushf(prefixes, *p, len, prefix); > } > > +char *git_default_branch_name(int short_name) > +{ > + const char *branch_name = getenv("GIT_TEST_DEFAULT_BRANCH_NAME"); > + char *from_config = NULL, *prefixed; > + > + /* > + * If the default branch name was not specified via the environment > + * variable GIT_TEST_DEFAULT_BRANCH_NAME, retrieve it from the config > + * setting core.defaultBranchName. If neither are set, fall back to the > + * hard-coded default. > + */ > + if (!branch_name || !*branch_name) { > + if (git_config_get_string("core.defaultbranchname", > + &from_config) < 0) > + die(_("Could not retrieve `core.defaultBranchName`")); > + > + if (from_config) > + branch_name = from_config; > + else > + branch_name = "master"; > + } > + > + if (short_name) > + return from_config ? from_config : xstrdup(branch_name); If short_name is set we return without validating the name is that intentional? > + > + /* prepend "refs/heads/" to the branch name */ > + prefixed = xstrfmt("refs/heads/%s", branch_name); > + if (check_refname_format(prefixed, 0)) > + die(_("invalid default branch name: '%s'"), branch_name); > + > + free(from_config); > + return prefixed; > +} > + > /* > * *string and *len will only be substituted, and *string returned (for > * later free()ing) if the string passed in is a magic short-hand form > diff --git a/refs.h b/refs.h > index a92d2c74c83..e8d4f6e2f13 100644 > --- a/refs.h > +++ b/refs.h > @@ -154,6 +154,12 @@ int repo_dwim_log(struct repository *r, const char *str, int len, struct object_ > int dwim_ref(const char *str, int len, struct object_id *oid, char **ref); > int dwim_log(const char *str, int len, struct object_id *oid, char **ref); > > +/* > + * Retrieves the name of the default branch. If `short_name` is non-zero, the > + * branch name will be prefixed with "refs/heads/". Isn't the other way around - the branch name is prefixed with "refs/heads/" if short is zero. > + */ > +char *git_default_branch_name(int short_name); > + > /* > * A ref_transaction represents a collection of reference updates that > * should succeed or fail together. > diff --git a/t/t0001-init.sh b/t/t0001-init.sh > index 1edd5aeb8f0..b144cd8f46b 100755 > --- a/t/t0001-init.sh > +++ b/t/t0001-init.sh > @@ -464,4 +464,24 @@ test_expect_success MINGW 'redirect std handles' ' > grep "Needed a single revision" output.txt > ' > > +test_expect_success 'custom default branch name from config' ' > + git config --global core.defaultbranchname nmb && In tests we usually use 'test_config' rather than 'git config' as the former automatically cleans up the config at the end of the test. > + GIT_TEST_DEFAULT_BRANCH_NAME= git init custom-config && > + git config --global --unset core.defaultbranchname && > + git -C custom-config symbolic-ref HEAD >actual && > + grep nmb actual > +' > + > +test_expect_success 'custom default branch name from env' ' > + GIT_TEST_DEFAULT_BRANCH_NAME=nmb git init custom-env && It would be good to test that this overrides the config setting Best Wishes Phillip > + git -C custom-env symbolic-ref HEAD >actual && > + grep nmb actual > +' > + > +test_expect_success 'invalid custom default branch name' ' > + test_must_fail env GIT_TEST_DEFAULT_BRANCH_NAME="with space" \ > + git init custom-invalid 2>err && > + test_i18ngrep "invalid default branch name" err > +' > + > test_done >

On the Git mailing list, Johannes Schindelin wrote (reply to this):

Hi Phillip, On Thu, 11 Jun 2020, Phillip Wood wrote: > On 10/06/2020 22:19, Don Goodman-Wilson via GitGitGadget wrote: > > From: Don Goodman-Wilson <don@goodman-wilson.com> > > > > There is a growing number of projects trying to avoid the non-inclusive > > name `master` in their repositories. > > I think it would be helpful to explain why 'master' is no-inclusive even > if it originates from the concept of a master copy. i.e. it suggests > master/slave even if git is not based on that concept. Unfortunately, we do not even have that defense: the term `master` was copied from BitKeeper, which firmly uses it in the `master/slave` context. See e.g. https://mail.gnome.org/archives/desktop-devel-list/2019-May/msg00066.html I added a _brief_ extension to the context to the first commit's commit message. However, I do not want to go into details here because _this_ patch series is only about empowering users to change their default main branch name. > Have you got some examples of projects that have changed and the names > that they are using? Yes, there are plenty examples, and I do not want to pick a tiny subset to demonstrate that. A more useful resource is probably this post: https://www.hanselman.com/blog/EasilyRenameYourGitDefaultBranchFromMasterToMain.aspx > I think it would be helpful if we can agree on a replacement for master > - if every repository uses a different name for its main branch it adds > an extra complication for new contributors to those projects. Sure, and that's what I thought we'd discuss, too, maybe at the meeting I proposed elsewhere (Emily started a new thread about it: https://lore.kernel.org/git/20200610222719.GE148632@google.com/). > > For existing repositories, this > > requires manual work. For new repositories, the only way to do that > > automatically is by copying all of Git's template directory, then > > hard-coding the desired default branch name into the `.git/HEAD` file, > > and then configuring `init.templateDir` to point to those copied > > template files. > > > > To make this process much less cumbersome, let's introduce support for > > `core.defaultBranchName`. That way, users won't need to keep their > > copied template files up to date, and won't interfere with default hooks > > installed by their administrators. > > > > While at it, also let users set the default branch name via the > > environment variable `GIT_TEST_DEFAULT_BRANCH_NAME`, > > I'm not sure we usually promote the use of GIT_TEST_... environment > variables outside of the test suite. True. Together with Alban's suggestion to make this purely work in the test suite (i.e. not even adjust the C code to respect that environment variable), you convinced me to (re-)move that part of the commit. > > diff --git a/refs.c b/refs.c > > index 224ff66c7bb..8499b3865cb 100644 > > --- a/refs.c > > +++ b/refs.c > > @@ -560,6 +560,40 @@ void expand_ref_prefix(struct argv_array *prefixes, const char *prefix) > > argv_array_pushf(prefixes, *p, len, prefix); > > } > > > > +char *git_default_branch_name(int short_name) > > +{ > > + const char *branch_name = getenv("GIT_TEST_DEFAULT_BRANCH_NAME"); > > + char *from_config = NULL, *prefixed; > > + > > + /* > > + * If the default branch name was not specified via the environment > > + * variable GIT_TEST_DEFAULT_BRANCH_NAME, retrieve it from the config > > + * setting core.defaultBranchName. If neither are set, fall back to the > > + * hard-coded default. > > + */ > > + if (!branch_name || !*branch_name) { > > + if (git_config_get_string("core.defaultbranchname", > > + &from_config) < 0) > > + die(_("Could not retrieve `core.defaultBranchName`")); > > + > > + if (from_config) > > + branch_name = from_config; > > + else > > + branch_name = "master"; > > + } > > + > > + if (short_name) > > + return from_config ? from_config : xstrdup(branch_name); > > If short_name is set we return without validating the name is that > intentional? No, unintentional. Thank you for pointing this out. It will be fixed in v2 (still working on it). > > + > > + /* prepend "refs/heads/" to the branch name */ > > + prefixed = xstrfmt("refs/heads/%s", branch_name); > > + if (check_refname_format(prefixed, 0)) > > + die(_("invalid default branch name: '%s'"), branch_name); > > + > > + free(from_config); > > + return prefixed; > > +} > > + > > /* > > * *string and *len will only be substituted, and *string returned (for > > * later free()ing) if the string passed in is a magic short-hand form > > diff --git a/refs.h b/refs.h > > index a92d2c74c83..e8d4f6e2f13 100644 > > --- a/refs.h > > +++ b/refs.h > > @@ -154,6 +154,12 @@ int repo_dwim_log(struct repository *r, const char *str, int len, struct object_ > > int dwim_ref(const char *str, int len, struct object_id *oid, char **ref); > > int dwim_log(const char *str, int len, struct object_id *oid, char **ref); > > > > +/* > > + * Retrieves the name of the default branch. If `short_name` is non-zero, the > > + * branch name will be prefixed with "refs/heads/". > > Isn't the other way around - the branch name is prefixed with > "refs/heads/" if short is zero. Absolutely. Thank you for your careful review, I read past this at least half a dozen times. > > + */ > > +char *git_default_branch_name(int short_name); > > + > > /* > > * A ref_transaction represents a collection of reference updates that > > * should succeed or fail together. > > diff --git a/t/t0001-init.sh b/t/t0001-init.sh > > index 1edd5aeb8f0..b144cd8f46b 100755 > > --- a/t/t0001-init.sh > > +++ b/t/t0001-init.sh > > @@ -464,4 +464,24 @@ test_expect_success MINGW 'redirect std handles' ' > > grep "Needed a single revision" output.txt > > ' > > > > +test_expect_success 'custom default branch name from config' ' > > + git config --global core.defaultbranchname nmb && > > In tests we usually use 'test_config' rather than 'git config' as the > former automatically cleans up the config at the end of the test. Right, and in this instance it is `test_config_global`. > > + GIT_TEST_DEFAULT_BRANCH_NAME= git init custom-config && > > + git config --global --unset core.defaultbranchname && > > + git -C custom-config symbolic-ref HEAD >actual && > > + grep nmb actual > > +' > > + > > +test_expect_success 'custom default branch name from env' ' > > + GIT_TEST_DEFAULT_BRANCH_NAME=nmb git init custom-env && > > It would be good to test that this overrides the config setting Except that we'll make this a thing that is internal to the test suite now. So this test case can go. Thank you for helping me improve the patch series! Dscho

On the Git mailing list, Junio C Hamano wrote (reply to this):

Johannes Schindelin <Johannes.Schindelin@gmx.de> writes: > I added a _brief_ extension to the context to the first commit's commit > message. However, I do not want to go into details here because _this_ > patch series is only about empowering users to change their default main > branch name. Sensible. And I do not think the planned follow-up work to rename 'master' to something else needs to be defended with lengthy history lessons. Sufficiently large part of the user population are unhappy with the use of the word 'master' as the default name of the primary branch in a newly created repository, and the mere fact that we are aware of that is good enough justification to move _away_ from 'master'. In other words, we do not have to explain why 'master' was bad, as it does not have to be bad for everybody to be replaced. But you need to defend that the new word you picked is something everybody is happy with. That is much harder ;-).

On the Git mailing list, Phillip Wood wrote (reply to this):

On 12/06/2020 17:51, Junio C Hamano wrote: > Johannes Schindelin <Johannes.Schindelin@gmx.de> writes: > >> I added a _brief_ extension to the context to the first commit's commit >> message. However, I do not want to go into details here because _this_ >> patch series is only about empowering users to change their default main >> branch name. > > [...] > > Sufficiently large part of the user population are unhappy with the > use of the word 'master' as the default name of the primary branch > in a newly created repository, and the mere fact that we are aware > of that is good enough justification to move _away_ from 'master'. > In other words, we do not have to explain why 'master' was bad, as > it does not have to be bad for everybody to be replaced. This expresses what I was trying to get at with my comments much more clearly than I managed - Thank you > > But you need to defend that the new word you picked is something > everybody is happy with. That is much harder ;-). Indeed, though I am more optimistic about that having seen a couple of people have indicated that they don't mind too much what we choose so long as it unlikely to cause future problems. Best Wishes Phillip

On the Git mailing list, Johannes Schindelin wrote (reply to this):

Hi Junio, On Fri, 12 Jun 2020, Junio C Hamano wrote: > Johannes Schindelin <Johannes.Schindelin@gmx.de> writes: > > > I added a _brief_ extension to the context to the first commit's commit > > message. However, I do not want to go into details here because _this_ > > patch series is only about empowering users to change their default main > > branch name. > > Sensible. > > And I do not think the planned follow-up work to rename 'master' to > something else needs to be defended with lengthy history lessons. Yes, I agree. It is probably sufficient to just point at a couple high-profile projects that already made the switch to `main`. > Sufficiently large part of the user population are unhappy with the > use of the word 'master' as the default name of the primary branch > in a newly created repository, and the mere fact that we are aware > of that is good enough justification to move _away_ from 'master'. Yes, even Pasky says he regrets the choice of term (see https://twitter.com/xpasky/status/1271477451756056577): I picked the names "master" (and "origin") in the early Git tooling back in 2005. (this probably means you shouldn't give much weight to my name preferences :) ) I have wished many times I would have named them "main" (and "upstream") instead. > In other words, we do not have to explain why 'master' was bad, as > it does not have to be bad for everybody to be replaced. > > But you need to defend that the new word you picked is something > everybody is happy with. That is much harder ;-). To be honest, I stopped looking for got arguments in favor of one name after a couple days, and instead focused on the consensus I saw: Chrome [*1*] and node.js [*2*] apparently stated publicly that they want to change their main branches to `main`, and GitLab [*3*] and GitHub [*4*] seem to intend to change the default for new repositories accordingly. It is not like we have to decide for the community (as we did back in 2005). I am actually quite relieved about that. Ciao, Dscho URL *1*: https://twitter.com/Una/status/1271180494944829441 URL *2*: https://github.com/nodejs/node/issues/33864 URL *3*: https://gitlab.com/gitlab-org/gitlab/-/issues/221164 URL *4*: https://twitter.com/natfriedman/status/1271253144442253312 (this is not really a public announcement, I agree, but it is a public Tweet by the CEO)

gitgitgadget · 2020-06-11T10:26:59Z

On the Git mailing list, Alban Gruin wrote (reply to this):

Hi Don & Johannes, Le 10/06/2020 à 23:19, Don Goodman-Wilson via GitGitGadget a écrit : > From: Don Goodman-Wilson <don@goodman-wilson.com> > > There is a growing number of projects trying to avoid the non-inclusive > name `master` in their repositories. For existing repositories, this > requires manual work. For new repositories, the only way to do that > automatically is by copying all of Git's template directory, then > hard-coding the desired default branch name into the `.git/HEAD` file, > and then configuring `init.templateDir` to point to those copied > template files. > > To make this process much less cumbersome, let's introduce support for > `core.defaultBranchName`. That way, users won't need to keep their > copied template files up to date, and won't interfere with default hooks > installed by their administrators. > > While at it, also let users set the default branch name via the > environment variable `GIT_TEST_DEFAULT_BRANCH_NAME`, in preparation for > adjusting Git's test suite to a more inclusive default branch name. As > is common in Git, the `GIT_TEST_*` variable takes precedence over the > config setting. > Why adding yet another environment variable instead of relying only on a config option? I understand it's for the tests, but can't we add a shell function in test-lib.sh (and friends) that tries to read `GIT_TEST_DEFAULT_BRANCH_NAME', and, if it exists, sets `core.defaultBranchName'? Cheers, Alban

On the Git mailing list, Junio C Hamano wrote (reply to this):

Alban Gruin <alban.gruin@gmail.com> writes: > Why adding yet another environment variable instead of relying only on a > config option? I understand it's for the tests, but can't we add a > shell function in test-lib.sh (and friends) that tries to read > `GIT_TEST_DEFAULT_BRANCH_NAME', and, if it exists, sets > `core.defaultBranchName'? Can you produce such a patch that does it cleanly? My knee jerk reaction is that I would suspect that you end up having to touch many places in the t/ scripts, but if you prove otherwise, that would certainly be appreciated. And no, git () { command git -c core.defaultBranchName=master "$@" } is not an acceptable solution.

On the Git mailing list, "brian m. carlson" wrote (reply to this):

--YLwdFo+Xu6B7B0Yp Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On 2020-06-11 at 23:14:46, Junio C Hamano wrote: > Alban Gruin <alban.gruin@gmail.com> writes: >=20 > > Why adding yet another environment variable instead of relying only on a > > config option? I understand it's for the tests, but can't we add a > > shell function in test-lib.sh (and friends) that tries to read > > `GIT_TEST_DEFAULT_BRANCH_NAME', and, if it exists, sets > > `core.defaultBranchName'? >=20 > Can you produce such a patch that does it cleanly? My knee jerk > reaction is that I would suspect that you end up having to touch > many places in the t/ scripts, but if you prove otherwise, that > would certainly be appreciated. >=20 > And no,=20 >=20 > git () { command git -c core.defaultBranchName=3Dmaster "$@" } >=20 > is not an acceptable solution. I would also be delighted to see such a solution, but my experience with the SHA-256 work tells me there's unlikely to be one. We do a lot of "git init" operations in random places in the test suite and as a consequence it's very hard to make a change without touching a large number of tests. If we were writing things today, perhaps we would use a function (e.g., test_init_repo or such) to wrap this case, but we unfortunately didn't think about that and we're stuck with what we have now unless someone retrofits the test suite. --=20 brian m. carlson: Houston, Texas, US OpenPGP: https://keybase.io/bk2204 --YLwdFo+Xu6B7B0Yp Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.2.20 (GNU/Linux) iHUEABYKAB0WIQQILOaKnbxl+4PRw5F8DEliiIeigQUCXuLCQwAKCRB8DEliiIei gfboAPwPOWvrtndE4Tf6OyE/Dlrn0w0VVNPWD6Wbo2G/I/jVHwD/QkWS8+mUYFKb f/yZFjgAyHz+el1vM15ysxgSkrQo6Qk= =SFrp -----END PGP SIGNATURE----- --YLwdFo+Xu6B7B0Yp--

On the Git mailing list, Johannes Schindelin wrote (reply to this):

Hi brian, On Thu, 11 Jun 2020, brian m. carlson wrote: > On 2020-06-11 at 23:14:46, Junio C Hamano wrote: > > Alban Gruin <alban.gruin@gmail.com> writes: > > > > > Why adding yet another environment variable instead of relying only on a > > > config option? I understand it's for the tests, but can't we add a > > > shell function in test-lib.sh (and friends) that tries to read > > > `GIT_TEST_DEFAULT_BRANCH_NAME', and, if it exists, sets > > > `core.defaultBranchName'? > > > > Can you produce such a patch that does it cleanly? My knee jerk > > reaction is that I would suspect that you end up having to touch > > many places in the t/ scripts, but if you prove otherwise, that > > would certainly be appreciated. > > > > And no, > > > > git () { command git -c core.defaultBranchName=master "$@" } > > > > is not an acceptable solution. > > I would also be delighted to see such a solution, but my experience with > the SHA-256 work tells me there's unlikely to be one. We do a lot of > "git init" operations in random places in the test suite and as a > consequence it's very hard to make a change without touching a large > number of tests. That's a valid point, indeed. > If we were writing things today, perhaps we would use a function (e.g., > test_init_repo or such) to wrap this case, but we unfortunately didn't > think about that and we're stuck with what we have now unless someone > retrofits the test suite. There is actually `test_create_repo` (see https://github.com/git/git/blob/v2.27.0/t/test-lib-functions.sh#L1145-L1159): # Most tests can use the created repository, but some may need to create # more. # Usage: test_create_repo <directory> test_create_repo () { test "$#" = 1 || BUG "not 1 parameter to test-create-repo" repo="$1" mkdir -p "$repo" ( cd "$repo" || error "Cannot setup test environment" "${GIT_TEST_INSTALLED:-$GIT_EXEC_PATH}/git$X" init \ "--template=$GIT_BUILD_DIR/templates/blt/" >&3 2>&4 || error "cannot run git init -- have you built things yet?" mv .git/hooks .git/hooks-disabled ) || exit } But I agree that few test scripts use it: $ git grep 'git init' v2.27.0 -- t/ | wc -l 765 $ git grep 'test_create_repo' v2.27.0 -- t/ | wc -l 296 Ciao, Dscho

On the Git mailing list, Alban Gruin wrote (reply to this):

Hi Junio, Le 12/06/2020 à 01:14, Junio C Hamano a écrit : > Alban Gruin <alban.gruin@gmail.com> writes: > >> Why adding yet another environment variable instead of relying only on a >> config option? I understand it's for the tests, but can't we add a >> shell function in test-lib.sh (and friends) that tries to read >> `GIT_TEST_DEFAULT_BRANCH_NAME', and, if it exists, sets >> `core.defaultBranchName'? > > Can you produce such a patch that does it cleanly? My knee jerk > reaction is that I would suspect that you end up having to touch > many places in the t/ scripts, but if you prove otherwise, that > would certainly be appreciated. > > And no, > > git () { command git -c core.defaultBranchName=master "$@" } > > is not an acceptable solution. > I wanted to to do something like this: if test -n "$GIT_TEST_DEFAULT_BRANCH_NAME"; then git config core.defaultBranchName "$GIT_TEST_DEFAULT_BRANCH_NAME" fi But since we do not have a repository to store the config, it won't work. Sorry for the noise. Alban

On the Git mailing list, Johannes Schindelin wrote (reply to this):

This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. --8323328-1464577387-1592125063=:56 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hi Alban, On Sat, 13 Jun 2020, Alban Gruin wrote: > Hi Junio, > > Le 12/06/2020 =C3=A0 01:14, Junio C Hamano a =C3=A9crit=C2=A0: > > Alban Gruin <alban.gruin@gmail.com> writes: > > > >> Why adding yet another environment variable instead of relying only o= n a > >> config option? I understand it's for the tests, but can't we add a > >> shell function in test-lib.sh (and friends) that tries to read > >> `GIT_TEST_DEFAULT_BRANCH_NAME', and, if it exists, sets > >> `core.defaultBranchName'? > > > > Can you produce such a patch that does it cleanly? My knee jerk > > reaction is that I would suspect that you end up having to touch > > many places in the t/ scripts, but if you prove otherwise, that > > would certainly be appreciated. > > > > And no, > > > > git () { command git -c core.defaultBranchName=3Dmaster "$@" } > > > > is not an acceptable solution. > > > > I wanted to to do something like this: > > if test -n "$GIT_TEST_DEFAULT_BRANCH_NAME"; > then > git config core.defaultBranchName "$GIT_TEST_DEFAULT_BRANCH_NAME" > fi > > But since we do not have a repository to store the config, it won't > work. Sorry for the noise. We actually would have `~/.gitconfig` because `HOME` is set to `t/trash directory.<test-name>/`. However, that would cause all kinds of issues when test scripts expect the directory to be pristine, containing only `.git/` but not `.gitconfig`. It was a good idea to bring up; I share brian's sentiment that it would have been nice if it would have worked out. Ciao, Dscho --8323328-1464577387-1592125063=:56--

On the Git mailing list, Jeff King wrote (reply to this):

On Sun, Jun 14, 2020 at 10:57:41AM +0200, Johannes Schindelin wrote: > > >> Why adding yet another environment variable instead of relying only on a > > >> config option? I understand it's for the tests, but can't we add a > > >> shell function in test-lib.sh (and friends) that tries to read > > >> `GIT_TEST_DEFAULT_BRANCH_NAME', and, if it exists, sets > > >> `core.defaultBranchName'? > > > > > > Can you produce such a patch that does it cleanly? My knee jerk > > > reaction is that I would suspect that you end up having to touch > > > many places in the t/ scripts, but if you prove otherwise, that > > > would certainly be appreciated. > > > > > > And no, > > > > > > git () { command git -c core.defaultBranchName=master "$@" } > > > > > > is not an acceptable solution. > > > > > > > I wanted to to do something like this: > > > > if test -n "$GIT_TEST_DEFAULT_BRANCH_NAME"; > > then > > git config core.defaultBranchName "$GIT_TEST_DEFAULT_BRANCH_NAME" > > fi > > > > But since we do not have a repository to store the config, it won't > > work. Sorry for the noise. > > We actually would have `~/.gitconfig` because `HOME` is set to `t/trash > directory.<test-name>/`. > > However, that would cause all kinds of issues when test scripts expect the > directory to be pristine, containing only `.git/` but not `.gitconfig`. Putting: GIT_CONFIG_PARAMETERS="'core.defaultBranchName=...'" into the environment would work (and yes, you need the single quotes embedded in the variable), and solves all of the complaints above. Further "git -c" invocations properly append to it. But: - there are a few tests which explicitly tweak that variable - it technically changes any tests of "-c" because now we'd never cover the case where we start without the variable defined I think baking in a special environment variable like you have is not so bad. If this did become too common a pattern, though (special test-only environment variables that do have a separate config option), I wouldn't be opposed to a GIT_TEST_CONFIG_PARAMETERS which takes precedence over other config, and comes with a big warning label that it shouldn't be relied upon outside the test suite. That's equally ugly to GIT_TEST_DEFAULT_BRANCH_NAME, but at least solves the problem once for all of them. I'm just not sure we have enough "all of them" to make it worth doing. -Peff

On the Git mailing list, Johannes Schindelin wrote (reply to this):

Hi Peff, On Tue, 16 Jun 2020, Jeff King wrote: > On Sun, Jun 14, 2020 at 10:57:41AM +0200, Johannes Schindelin wrote: > > > > >> Why adding yet another environment variable instead of relying only on a > > > >> config option? I understand it's for the tests, but can't we add a > > > >> shell function in test-lib.sh (and friends) that tries to read > > > >> `GIT_TEST_DEFAULT_BRANCH_NAME', and, if it exists, sets > > > >> `core.defaultBranchName'? > > > > > > > > Can you produce such a patch that does it cleanly? My knee jerk > > > > reaction is that I would suspect that you end up having to touch > > > > many places in the t/ scripts, but if you prove otherwise, that > > > > would certainly be appreciated. > > > > > > > > And no, > > > > > > > > git () { command git -c core.defaultBranchName=master "$@" } > > > > > > > > is not an acceptable solution. > > > > > > > > > > I wanted to to do something like this: > > > > > > if test -n "$GIT_TEST_DEFAULT_BRANCH_NAME"; > > > then > > > git config core.defaultBranchName "$GIT_TEST_DEFAULT_BRANCH_NAME" > > > fi > > > > > > But since we do not have a repository to store the config, it won't > > > work. Sorry for the noise. > > > > We actually would have `~/.gitconfig` because `HOME` is set to `t/trash > > directory.<test-name>/`. > > > > However, that would cause all kinds of issues when test scripts expect the > > directory to be pristine, containing only `.git/` but not `.gitconfig`. > > Putting: > > GIT_CONFIG_PARAMETERS="'core.defaultBranchName=...'" > > into the environment would work (and yes, you need the single quotes > embedded in the variable), and solves all of the complaints above. > Further "git -c" invocations properly append to it. But: > > - there are a few tests which explicitly tweak that variable > > - it technically changes any tests of "-c" because now we'd never > cover the case where we start without the variable defined Indeed. > I think baking in a special environment variable like you have is not so > bad. If this did become too common a pattern, though (special test-only > environment variables that do have a separate config option), I wouldn't > be opposed to a GIT_TEST_CONFIG_PARAMETERS which takes precedence over > other config, and comes with a big warning label that it shouldn't be > relied upon outside the test suite. That's equally ugly to > GIT_TEST_DEFAULT_BRANCH_NAME, but at least solves the problem once for > all of them. I'm just not sure we have enough "all of them" to make it > worth doing. FWIW I do not plan on using that variable for a long time. And it is not in this here patch series any longer, so let's discuss it in the future patch contribution of mine. Thanks, Dscho

gitgitgadget · 2020-06-24T16:18:22Z

On the Git mailing list, Junio C Hamano wrote (reply to this):

"Johannes Schindelin via GitGitGadget" <gitgitgadget@gmail.com> writes: > From: Johannes Schindelin <johannes.schindelin@gmx.de> > > In the context of many projects renaming their primary branch names away > from `master`, Git wants to stop treating the `master` branch specially. > > Let's start with `git fmt-merge-msg`. > > Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> > --- > fmt-merge-msg.c | 5 +- > t/t1507-rev-parse-upstream.sh | 2 +- > t/t4013-diff-various.sh | 4 +- > t/t4013/diff.log_--decorate=full_--all | 2 +- > t/t4013/diff.log_--decorate_--all | 2 +- > ...--patch-with-stat_--summary_master_--_dir_ | 2 +- > t/t4013/diff.log_--patch-with-stat_master | 2 +- > .../diff.log_--patch-with-stat_master_--_dir_ | 2 +- > ...ot_--cc_--patch-with-stat_--summary_master | 2 +- > ..._--root_--patch-with-stat_--summary_master | 2 +- > .../diff.log_--root_--patch-with-stat_master | 2 +- > ...root_-c_--patch-with-stat_--summary_master | 2 +- > t/t4013/diff.log_--root_-p_master | 2 +- > t/t4013/diff.log_--root_master | 2 +- > t/t4013/diff.log_-m_-p_--first-parent_master | 2 +- > t/t4013/diff.log_-m_-p_master | 4 +- > t/t4013/diff.log_-p_--first-parent_master | 2 +- > t/t4013/diff.log_-p_master | 2 +- > t/t4013/diff.log_master | 2 +- > t/t4013/diff.show_--first-parent_master | 2 +- > t/t4013/diff.show_-c_master | 2 +- > t/t4013/diff.show_-m_master | 4 +- > t/t4013/diff.show_master | 2 +- > ...ot_--cc_--patch-with-stat_--summary_master | 2 +- > ...root_-c_--patch-with-stat_--summary_master | 2 +- > t/t4202-log.sh | 72 +++++++++---------- > t/t6200-fmt-merge-msg.sh | 36 +++++----- > t/t7600-merge.sh | 14 ++-- > t/t7608-merge-messages.sh | 10 +-- > 29 files changed, 94 insertions(+), 97 deletions(-) This must have been tedious as the tests with merge commits are all over the place (I know updating t4013 would not have been too much of the work as it has its own self-update knob, but it still is a lot of work to verify that the changes make sense). Thanks.

On the Git mailing list, Johannes Schindelin wrote (reply to this):

Hi Junio, On Wed, 24 Jun 2020, Junio C Hamano wrote: > "Johannes Schindelin via GitGitGadget" <gitgitgadget@gmail.com> > writes: > > > From: Johannes Schindelin <johannes.schindelin@gmx.de> > > > > In the context of many projects renaming their primary branch names away > > from `master`, Git wants to stop treating the `master` branch specially. > > > > Let's start with `git fmt-merge-msg`. > > > > Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> > > --- > > fmt-merge-msg.c | 5 +- > > t/t1507-rev-parse-upstream.sh | 2 +- > > t/t4013-diff-various.sh | 4 +- > > t/t4013/diff.log_--decorate=full_--all | 2 +- > > t/t4013/diff.log_--decorate_--all | 2 +- > > ...--patch-with-stat_--summary_master_--_dir_ | 2 +- > > t/t4013/diff.log_--patch-with-stat_master | 2 +- > > .../diff.log_--patch-with-stat_master_--_dir_ | 2 +- > > ...ot_--cc_--patch-with-stat_--summary_master | 2 +- > > ..._--root_--patch-with-stat_--summary_master | 2 +- > > .../diff.log_--root_--patch-with-stat_master | 2 +- > > ...root_-c_--patch-with-stat_--summary_master | 2 +- > > t/t4013/diff.log_--root_-p_master | 2 +- > > t/t4013/diff.log_--root_master | 2 +- > > t/t4013/diff.log_-m_-p_--first-parent_master | 2 +- > > t/t4013/diff.log_-m_-p_master | 4 +- > > t/t4013/diff.log_-p_--first-parent_master | 2 +- > > t/t4013/diff.log_-p_master | 2 +- > > t/t4013/diff.log_master | 2 +- > > t/t4013/diff.show_--first-parent_master | 2 +- > > t/t4013/diff.show_-c_master | 2 +- > > t/t4013/diff.show_-m_master | 4 +- > > t/t4013/diff.show_master | 2 +- > > ...ot_--cc_--patch-with-stat_--summary_master | 2 +- > > ...root_-c_--patch-with-stat_--summary_master | 2 +- > > t/t4202-log.sh | 72 +++++++++---------- > > t/t6200-fmt-merge-msg.sh | 36 +++++----- > > t/t7600-merge.sh | 14 ++-- > > t/t7608-merge-messages.sh | 10 +-- > > 29 files changed, 94 insertions(+), 97 deletions(-) > > This must have been tedious as the tests with merge commits are all > over the place (I know updating t4013 would not have been too much > of the work as it has its own self-update knob, but it still is a > lot of work to verify that the changes make sense). I missed the self-update knob, but in any case, I would not have used it, anyway, to make sure that I do look closely at all the sites. Ciao, Dscho

gitgitgadget · 2020-06-29T18:52:48Z

On the Git mailing list, Đoàn Trần Công Danh wrote (reply to this):

On 2020-06-24 14:46:28+0000, Johannes Schindelin via GitGitGadget <gitgitgadget@gmail.com> wrote: > From: Johannes Schindelin <johannes.schindelin@gmx.de> > > In the context of many projects renaming their primary branch names away > from `master`, Git wants to stop treating the `master` branch specially. > > Let's start with `git fmt-merge-msg`. > > Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> > --- Hi Dscho, This change will also affect git-subtree test. We'll need this patch for subtree: ----------------8<------------------- From: =?UTF-8?q?=C4=90o=C3=A0n=20Tr=E1=BA=A7n=20C=C3=B4ng=20Danh?= <congdanhqx@gmail.com> Date: Mon, 29 Jun 2020 22:56:37 +0700 Subject: [PATCH] contrib: subtree: adjust test to change in fmt-merge-msg MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit We're starting to stop treating `master' specially in fmt-merge-msg. Adjust the test to reflect that change. Signed-off-by: Đoàn Trần Công Danh <congdanhqx@gmail.com> --- contrib/subtree/t/t7900-subtree.sh | 6 ++++-- 1 file changed, 4 insertions(+), 2 deletions(-) diff --git a/contrib/subtree/t/t7900-subtree.sh b/contrib/subtree/t/t7900-subtree.sh index 57ff4b25c1..53d7accf94 100755 --- a/contrib/subtree/t/t7900-subtree.sh +++ b/contrib/subtree/t/t7900-subtree.sh @@ -196,7 +196,8 @@ test_expect_success 'merge new subproj history into sub dir/ with --prefix' ' cd "$subtree_test_count" && git fetch ./"sub proj" master && git subtree merge --prefix="sub dir" FETCH_HEAD && - check_equal "$(last_commit_message)" "Merge commit '\''$(git rev-parse FETCH_HEAD)'\''" + check_equal "$(last_commit_message)" \ + "Merge commit '\''$(git rev-parse FETCH_HEAD)'\'' into master" ) ' @@ -273,7 +274,8 @@ test_expect_success 'merge new subproj history into subdir/ with a slash appende cd "$test_count" && git fetch ./subproj master && git subtree merge --prefix=subdir/ FETCH_HEAD && - check_equal "$(last_commit_message)" "Merge commit '\''$(git rev-parse FETCH_HEAD)'\''" + check_equal "$(last_commit_message)" \ + "Merge commit '\''$(git rev-parse FETCH_HEAD)'\'' into master" ) ' -- 2.27.0.111.gc72c7da667 Danh

On the Git mailing list, Johannes Schindelin wrote (reply to this):

This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. --8323328-1652750913-1593437267=:56 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hi Danh, On Mon, 29 Jun 2020, =C4=90o=C3=A0n Tr=E1=BA=A7n C=C3=B4ng Danh wrote: > On 2020-06-24 14:46:28+0000, Johannes Schindelin via GitGitGadget <gitgi= tgadget@gmail.com> wrote: > > From: Johannes Schindelin <johannes.schindelin@gmx.de> > > > > In the context of many projects renaming their primary branch names aw= ay > > from `master`, Git wants to stop treating the `master` branch speciall= y. > > > > Let's start with `git fmt-merge-msg`. > > > > Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> > > --- > > Hi Dscho, > > This change will also affect git-subtree test. Good point. The patch looks good. I wonder whether we should also address these: Documentation/git-rebase.txt:* Merge branch 'report-a-bug' Documentation/git-rebase.txt:* | Merge branch 'refactor-button' Documentation/git-switch.txt:HEAD is now at 9fc9555312 Merge branch 'cc/sh= ared-index-permbits' Documentation/howto/using-signed-tag-in-pull-request.txt: Merge tag 'frotz= -for-xyzzy' of example.com:/git/froboz.git/ Documentation/howto/using-signed-tag-in-pull-request.txt: Merge tag 'f= rotz-for-xyzzy' of example.com:/git/froboz.git/ t/t7606-merge-custom.sh:* (HEAD, master) Merge commit 'c3' The first three matches are in manual pages, the next two in technical documentation, and the last one in a comment in one of the test scripts. So none of them are super critical, but maybe there are different opinions? Ciao, Dscho > We'll need this patch for subtree: > ----------------8<------------------- > From: =3D?UTF-8?q?=3DC4=3D90o=3DC3=3DA0n=3D20Tr=3DE1=3DBA=3DA7n=3D20C=3D= C3=3DB4ng=3D20Danh?=3D > <congdanhqx@gmail.com> > Date: Mon, 29 Jun 2020 22:56:37 +0700 > Subject: [PATCH] contrib: subtree: adjust test to change in fmt-merge-ms= g > MIME-Version: 1.0 > Content-Type: text/plain; charset=3DUTF-8 > Content-Transfer-Encoding: 8bit > > We're starting to stop treating `master' specially in fmt-merge-msg. > Adjust the test to reflect that change. > > Signed-off-by: =C4=90o=C3=A0n Tr=E1=BA=A7n C=C3=B4ng Danh <congdanhqx@gm= ail.com> > --- > contrib/subtree/t/t7900-subtree.sh | 6 ++++-- > 1 file changed, 4 insertions(+), 2 deletions(-) > > diff --git a/contrib/subtree/t/t7900-subtree.sh b/contrib/subtree/t/t790= 0-subtree.sh > index 57ff4b25c1..53d7accf94 100755 > --- a/contrib/subtree/t/t7900-subtree.sh > +++ b/contrib/subtree/t/t7900-subtree.sh > @@ -196,7 +196,8 @@ test_expect_success 'merge new subproj history into = sub dir/ with --prefix' ' > cd "$subtree_test_count" && > git fetch ./"sub proj" master && > git subtree merge --prefix=3D"sub dir" FETCH_HEAD && > - check_equal "$(last_commit_message)" "Merge commit '\''$(git rev-pars= e FETCH_HEAD)'\''" > + check_equal "$(last_commit_message)" \ > + "Merge commit '\''$(git rev-parse FETCH_HEAD)'\'' into master" > ) > ' > > @@ -273,7 +274,8 @@ test_expect_success 'merge new subproj history into = subdir/ with a slash appende > cd "$test_count" && > git fetch ./subproj master && > git subtree merge --prefix=3Dsubdir/ FETCH_HEAD && > - check_equal "$(last_commit_message)" "Merge commit '\''$(git rev-pars= e FETCH_HEAD)'\''" > + check_equal "$(last_commit_message)" \ > + "Merge commit '\''$(git rev-parse FETCH_HEAD)'\'' into master" > ) > ' > > -- > 2.27.0.111.gc72c7da667 > Danh > --8323328-1652750913-1593437267=:56--

On the Git mailing list, Đoàn Trần Công Danh wrote (reply to this):

Hi Dscho, On 2020-06-29 15:27:44+0200, Johannes Schindelin <Johannes.Schindelin@gmx.de> wrote: > > This change will also affect git-subtree test. > > Good point. The patch looks good. I wonder whether we should also address > these: > > Documentation/git-rebase.txt:* Merge branch 'report-a-bug' > Documentation/git-rebase.txt:* | Merge branch 'refactor-button' > Documentation/git-switch.txt:HEAD is now at 9fc9555312 Merge branch 'cc/shared-index-permbits' > Documentation/howto/using-signed-tag-in-pull-request.txt: Merge tag 'frotz-for-xyzzy' of example.com:/git/froboz.git/ > Documentation/howto/using-signed-tag-in-pull-request.txt: Merge tag 'frotz-for-xyzzy' of example.com:/git/froboz.git/ > t/t7606-merge-custom.sh:* (HEAD, master) Merge commit 'c3' > > The first three matches are in manual pages, the next two in technical > documentation, and the last one in a comment in one of the test scripts. > So none of them are super critical, but maybe there are different > opinions? In _my very opinion_, I don't think it's that critical. We allow git merge --edit and git fmt-merge-msg -m. Someone may have configured their Git to remove branch name already. And some others may always remove the target branch manually. We probably don't want to introduce another master occurence. (For sideline watcher: Please not argue on this, I don't have any opinions about the word: master.) If there're a consensus on changing those documentation, I won't mind to do that manual work ;) The test is a different story, since some (or most?) distro enable check (or test) phase for their build infrastructure. And, we shouldn't break their infrastructures. > > Ciao, > Dscho > > > We'll need this patch for subtree: > > ----------------8<------------------- > > From: =?UTF-8?q?=C4=90o=C3=A0n=20Tr=E1=BA=A7n=20C=C3=B4ng=20Danh?= > > <congdanhqx@gmail.com> > > Date: Mon, 29 Jun 2020 22:56:37 +0700 > > Subject: [PATCH] contrib: subtree: adjust test to change in fmt-merge-msg > > MIME-Version: 1.0 > > Content-Type: text/plain; charset=UTF-8 > > Content-Transfer-Encoding: 8bit > > > > We're starting to stop treating `master' specially in fmt-merge-msg. > > Adjust the test to reflect that change. > > > > Signed-off-by: Đoàn Trần Công Danh <congdanhqx@gmail.com> > > --- > > contrib/subtree/t/t7900-subtree.sh | 6 ++++-- > > 1 file changed, 4 insertions(+), 2 deletions(-) > > > > diff --git a/contrib/subtree/t/t7900-subtree.sh b/contrib/subtree/t/t7900-subtree.sh > > index 57ff4b25c1..53d7accf94 100755 > > --- a/contrib/subtree/t/t7900-subtree.sh > > +++ b/contrib/subtree/t/t7900-subtree.sh > > @@ -196,7 +196,8 @@ test_expect_success 'merge new subproj history into sub dir/ with --prefix' ' > > cd "$subtree_test_count" && > > git fetch ./"sub proj" master && > > git subtree merge --prefix="sub dir" FETCH_HEAD && > > - check_equal "$(last_commit_message)" "Merge commit '\''$(git rev-parse FETCH_HEAD)'\''" > > + check_equal "$(last_commit_message)" \ > > + "Merge commit '\''$(git rev-parse FETCH_HEAD)'\'' into master" > > ) > > ' > > > > @@ -273,7 +274,8 @@ test_expect_success 'merge new subproj history into subdir/ with a slash appende > > cd "$test_count" && > > git fetch ./subproj master && > > git subtree merge --prefix=subdir/ FETCH_HEAD && > > - check_equal "$(last_commit_message)" "Merge commit '\''$(git rev-parse FETCH_HEAD)'\''" > > + check_equal "$(last_commit_message)" \ > > + "Merge commit '\''$(git rev-parse FETCH_HEAD)'\'' into master" > > ) > > ' > > > > -- > > 2.27.0.111.gc72c7da667 > > Danh > > -- Danh

On the Git mailing list, Johannes Schindelin wrote (reply to this):

This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. --8323328-439506614-1593599949=:56 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hi Danh, On Tue, 30 Jun 2020, =C4=90o=C3=A0n Tr=E1=BA=A7n C=C3=B4ng Danh wrote: > On 2020-06-29 15:27:44+0200, Johannes Schindelin <Johannes.Schindelin@gm= x.de> wrote: > > > This change will also affect git-subtree test. > > > > Good point. The patch looks good. I wonder whether we should also addr= ess > > these: > > > > Documentation/git-rebase.txt:* Merge branch 'report-a-bug' > > Documentation/git-rebase.txt:* | Merge branch 'refactor-button' > > Documentation/git-switch.txt:HEAD is now at 9fc9555312 Merge branch 'c= c/shared-index-permbits' > > Documentation/howto/using-signed-tag-in-pull-request.txt: Merge tag 'f= rotz-for-xyzzy' of example.com:/git/froboz.git/ > > Documentation/howto/using-signed-tag-in-pull-request.txt: Merge ta= g 'frotz-for-xyzzy' of example.com:/git/froboz.git/ > > t/t7606-merge-custom.sh:* (HEAD, master) Merge commit 'c3' > > > > The first three matches are in manual pages, the next two in technical > > documentation, and the last one in a comment in one of the test script= s. > > So none of them are super critical, but maybe there are different > > opinions? > > In _my very opinion_, I don't think it's that critical. > We allow git merge --edit and git fmt-merge-msg -m. > Someone may have configured their Git to remove branch name already. > And some others may always remove the target branch manually. > We probably don't want to introduce another master occurence. > (For sideline watcher: Please not argue on this, > I don't have any opinions about the word: master.) True. > If there're a consensus on changing those documentation, > I won't mind to do that manual work ;) I actually agree that it is not _really_ necessary. > The test is a different story, since some (or most?) distro enable > check (or test) phase for their build infrastructure. > And, we shouldn't break their infrastructures. Actually, the hit in t7606 is in the initial _comment_. So I highly doubt that it would break any build infrastructure to leave it alone. Ciao, Dscho > > > > Ciao, > > Dscho > > > > > We'll need this patch for subtree: > > > ----------------8<------------------- > > > From: =3D?UTF-8?q?=3DC4=3D90o=3DC3=3DA0n=3D20Tr=3DE1=3DBA=3DA7n=3D20= C=3DC3=3DB4ng=3D20Danh?=3D > > > <congdanhqx@gmail.com> > > > Date: Mon, 29 Jun 2020 22:56:37 +0700 > > > Subject: [PATCH] contrib: subtree: adjust test to change in fmt-merg= e-msg > > > MIME-Version: 1.0 > > > Content-Type: text/plain; charset=3DUTF-8 > > > Content-Transfer-Encoding: 8bit > > > > > > We're starting to stop treating `master' specially in fmt-merge-msg. > > > Adjust the test to reflect that change. > > > > > > Signed-off-by: =C4=90o=C3=A0n Tr=E1=BA=A7n C=C3=B4ng Danh <congdanhq= x@gmail.com> > > > --- > > > contrib/subtree/t/t7900-subtree.sh | 6 ++++-- > > > 1 file changed, 4 insertions(+), 2 deletions(-) > > > > > > diff --git a/contrib/subtree/t/t7900-subtree.sh b/contrib/subtree/t/= t7900-subtree.sh > > > index 57ff4b25c1..53d7accf94 100755 > > > --- a/contrib/subtree/t/t7900-subtree.sh > > > +++ b/contrib/subtree/t/t7900-subtree.sh > > > @@ -196,7 +196,8 @@ test_expect_success 'merge new subproj history i= nto sub dir/ with --prefix' ' > > > cd "$subtree_test_count" && > > > git fetch ./"sub proj" master && > > > git subtree merge --prefix=3D"sub dir" FETCH_HEAD && > > > - check_equal "$(last_commit_message)" "Merge commit '\''$(git rev-= parse FETCH_HEAD)'\''" > > > + check_equal "$(last_commit_message)" \ > > > + "Merge commit '\''$(git rev-parse FETCH_HEAD)'\'' into master" > > > ) > > > ' > > > > > > @@ -273,7 +274,8 @@ test_expect_success 'merge new subproj history i= nto subdir/ with a slash appende > > > cd "$test_count" && > > > git fetch ./subproj master && > > > git subtree merge --prefix=3Dsubdir/ FETCH_HEAD && > > > - check_equal "$(last_commit_message)" "Merge commit '\''$(git rev-= parse FETCH_HEAD)'\''" > > > + check_equal "$(last_commit_message)" \ > > > + "Merge commit '\''$(git rev-parse FETCH_HEAD)'\'' into master" > > > ) > > > ' > > > > > > -- > > > 2.27.0.111.gc72c7da667 > > > Danh > > > > > > -- > Danh > --8323328-439506614-1593599949=:56--

On the Git mailing list, Junio C Hamano wrote (reply to this):

Johannes Schindelin <Johannes.Schindelin@gmx.de> writes: >> In _my very opinion_, I don't think it's that critical. >> We allow git merge --edit and git fmt-merge-msg -m. >> ... > > True. > >> If there're a consensus on changing those documentation, >> I won't mind to do that manual work ;) > > I actually agree that it is not _really_ necessary. > >> The test is a different story, since some (or most?) distro enable >> check (or test) phase for their build infrastructure. >> And, we shouldn't break their infrastructures. > > Actually, the hit in t7606 is in the initial _comment_. So I highly doubt > that it would break any build infrastructure to leave it alone. I guess it's settled, then. Thank you to all for being extra careful.

gitgitgadget · 2020-06-16T13:53:49Z

On the Git mailing list, Jeff King wrote (reply to this):

On Mon, Jun 15, 2020 at 12:50:16PM +0000, Johannes Schindelin via GitGitGadget wrote: > From: Johannes Schindelin <johannes.schindelin@gmx.de> > > The default name of the main branch in new repositories can now be > configured. The `testsvn` remote helper translates the remote Subversion > repository's branch name `trunk` to the hard-coded name `master`. > Clearly, the intention was to make the name align with Git's detaults. s/detaults/defaults/ :) I'd agree that moving this to Git's default name makes sense. Though my overall preference is still to delete this whole testsvn thing entirely (I have some other pending tree-wide changes that are being held up by it, too). After getting "would you mind holding off until..." from Jonathan in [1], I've been waiting almost 2 years. Maybe now is the time? -Peff [1] https://lore.kernel.org/git/20180818052605.GA241538@aiede.svl.corp.google.com/

On the Git mailing list, Johannes Schindelin wrote (reply to this):

Hi Peff, On Tue, 16 Jun 2020, Jeff King wrote: > On Mon, Jun 15, 2020 at 12:50:16PM +0000, Johannes Schindelin via GitGitGadget wrote: > > > From: Johannes Schindelin <johannes.schindelin@gmx.de> > > > > The default name of the main branch in new repositories can now be > > configured. The `testsvn` remote helper translates the remote Subversion > > repository's branch name `trunk` to the hard-coded name `master`. > > Clearly, the intention was to make the name align with Git's detaults. > > s/detaults/defaults/ :) :-) Will fix. > I'd agree that moving this to Git's default name makes sense. Okay. > Though my overall preference is still to delete this whole testsvn thing > entirely (I have some other pending tree-wide changes that are being > held up by it, too). After getting "would you mind holding off until..." > from Jonathan in [1], I've been waiting almost 2 years. Maybe now is the > time? I wouldn't mind dropping `testsvn`, seeing as there are fewer and fewer users of `git svn` (and even those are unlikely to switch to `testsvn`, should that ever become production-ready). Having said that, this is an orthogonal issue to the purpose of this patch series. And I would really like to get this patch series into a shape that can be merged down to `next` soon. Thank you, Dscho > > -Peff > > [1] https://lore.kernel.org/git/20180818052605.GA241538@aiede.svl.corp.google.com/ >

gitgitgadget · 2020-06-24T01:14:05Z

On the Git mailing list, Junio C Hamano wrote (reply to this):

"Johannes Schindelin via GitGitGadget" <gitgitgadget@gmail.com> writes: > diff --git a/remote.c b/remote.c > index 534c6426f1..965129adc3 100644 > --- a/remote.c > +++ b/remote.c > @@ -276,7 +276,7 @@ static void read_branches_file(struct remote *remote) > > /* > * The branches file would have URL and optionally > - * #branch specified. The "master" (or specified) branch is > + * #branch specified. The main (or specified) branch is > * fetched and stored in the local branch matching the > * remote name. > */ Isn't this a bit premature here?

On the Git mailing list, Johannes Schindelin wrote (reply to this):

Hi Junio, On Tue, 23 Jun 2020, Junio C Hamano wrote: > "Johannes Schindelin via GitGitGadget" <gitgitgadget@gmail.com> > writes: > > > diff --git a/remote.c b/remote.c > > index 534c6426f1..965129adc3 100644 > > --- a/remote.c > > +++ b/remote.c > > @@ -276,7 +276,7 @@ static void read_branches_file(struct remote *remote) > > > > /* > > * The branches file would have URL and optionally > > - * #branch specified. The "master" (or specified) branch is > > + * #branch specified. The main (or specified) branch is > > * fetched and stored in the local branch matching the > > * remote name. > > */ > > Isn't this a bit premature here? Actually, it is just wrong. It should talk about the default branch instead. Ciao, Dscho

gitgitgadget · 2020-06-24T00:37:58Z

On the Git mailing list, Junio C Hamano wrote (reply to this):

"Johannes Schindelin via GitGitGadget" <gitgitgadget@gmail.com> writes: > @@ -1046,7 +1046,7 @@ static int push_refs(struct transport *transport, > if (!remote_refs) { > fprintf(stderr, > _("No refs in common and none specified; doing nothing.\n" > - "Perhaps you should specify a branch such as 'master'.\n")); > + "Perhaps you should specify a specific branch.\n")); Hmph, not just "specify a branch."? Maybe it is just me, but "specify a specific branch" did not roll well on my tongue.

On the Git mailing list, Johannes Schindelin wrote (reply to this):

Hi Junio, On Tue, 23 Jun 2020, Junio C Hamano wrote: > "Johannes Schindelin via GitGitGadget" <gitgitgadget@gmail.com> > writes: > > > @@ -1046,7 +1046,7 @@ static int push_refs(struct transport *transport, > > if (!remote_refs) { > > fprintf(stderr, > > _("No refs in common and none specified; doing nothing.\n" > > - "Perhaps you should specify a branch such as 'master'.\n")); > > + "Perhaps you should specify a specific branch.\n")); > > Hmph, not just "specify a branch."? Maybe it is just me, but > "specify a specific branch" did not roll well on my tongue. Oh well. "Perhaps you should specify a branch" sounded too judgmental to me, but I'm not a native speaker, so I simply removed the word "specific". Ciao, Dscho

On the Git mailing list, Junio C Hamano wrote (reply to this):

Johannes Schindelin <Johannes.Schindelin@gmx.de> writes: > Hi Junio, > > On Tue, 23 Jun 2020, Junio C Hamano wrote: > >> "Johannes Schindelin via GitGitGadget" <gitgitgadget@gmail.com> >> writes: >> >> > @@ -1046,7 +1046,7 @@ static int push_refs(struct transport *transport, >> > if (!remote_refs) { >> > fprintf(stderr, >> > _("No refs in common and none specified; doing nothing.\n" >> > - "Perhaps you should specify a branch such as 'master'.\n")); >> > + "Perhaps you should specify a specific branch.\n")); >> >> Hmph, not just "specify a branch."? Maybe it is just me, but >> "specify a specific branch" did not roll well on my tongue. > > Oh well. "Perhaps you should specify a branch" sounded too judgmental to > me, but I'm not a native speaker, so I simply removed the word "specific". I'm not either. Note that when I say "maybe it is just me", I usually am not asking to change anything.

On the Git mailing list, Johannes Schindelin wrote (reply to this):

Hi Junio, On Wed, 24 Jun 2020, Junio C Hamano wrote: > Johannes Schindelin <Johannes.Schindelin@gmx.de> writes: > > > On Tue, 23 Jun 2020, Junio C Hamano wrote: > > > >> "Johannes Schindelin via GitGitGadget" <gitgitgadget@gmail.com> > >> writes: > >> > >> > @@ -1046,7 +1046,7 @@ static int push_refs(struct transport *transport, > >> > if (!remote_refs) { > >> > fprintf(stderr, > >> > _("No refs in common and none specified; doing nothing.\n" > >> > - "Perhaps you should specify a branch such as 'master'.\n")); > >> > + "Perhaps you should specify a specific branch.\n")); > >> > >> Hmph, not just "specify a branch."? Maybe it is just me, but > >> "specify a specific branch" did not roll well on my tongue. > > > > Oh well. "Perhaps you should specify a branch" sounded too judgmental to > > me, but I'm not a native speaker, so I simply removed the word "specific". > > I'm not either. We should start a society or something ;-) > Note that when I say "maybe it is just me", I usually am not asking to > change anything. Of course! In this instance, your suggestion made me think and prefer the non-repetitive version (because let's face it, taking out that word did not make it any more or less judgemental). Ciao, Dscho

-Original file line number
+Diff line change
@@ -1,3 +1,7 @@
     init.templateDir::
     	Specify the directory from which templates will be copied.
     	(See the "TEMPLATE DIRECTORY" section of linkgit:git-init[1].)
+    init.defaultBranch::
+    	Allows overriding the default branch name e.g. when initializing
+    	a new repository or when cloning an empty repository.

-Original file line number
+Diff line change
@@ Expand Up / @@ -12,7 +12,7 @@ SYNOPSIS @@
     	[-v [--abbrev=<length> | --no-abbrev]]
     	[--column[=<options>] | --no-column] [--sort=<key>]
     	[(--merged | --no-merged) [<commit>]]
-    	[--contains [<commit]] [--no-contains [<commit>]]
+    	[--contains [<commit>]] [--no-contains [<commit>]]
     	[--points-at <object>] [--format=<format>]
     	[(-r | --remotes) | (-a | --all)]
     	[--list] [<pattern>...]
@@ Expand Down @@

-Original file line number
+Diff line change
@@ Expand Up @@
     branch. This is useful e.g. to maintain minimal clones of the default
     branch of some repository for search indexing.
-    --recurse-submodules[=<pathspec]::
+    --recurse-submodules[=<pathspec>]::
     	After the clone is created, initialize and clone submodules
     	within based on the provided pathspec.  If no pathspec is
     	provided, all submodules are initialized and cloned.
@@ Expand Down @@

-Original file line number
+Diff line change
@@ Expand Up @@
     	free(key);
     	if (!branch)
-    		return "master";
+    		return "HEAD";
     	if (!strcmp(branch, ".")) {
     		const char *refname = resolve_ref_unsafe("HEAD", 0, NULL, NULL);
@@ Expand Down @@

-Original file line number
+Diff line change
@@ Expand Up / @@ -628,7 +628,7 @@ int path_inside_repo(const char *prefix, const char *path); @@
     int init_db(const char *git_dir, const char *real_git_dir,
     	    const char *template_dir, int hash_algo,
-    	    unsigned int flags);
+    	    const char *initial_branch, unsigned int flags);
     void initialize_repository_version(int hash_algo);
     void sanitize_stdfds(void);
@@ Expand Down @@

-Original file line number
+Diff line change
@@ Expand Up / @@ -10,7 +10,8 @@ SYNOPSIS @@
     --------
     [verse]
     'git init' [-q | --quiet] [--bare] [--template=<template_directory>]
-    	  [--separate-git-dir <git dir>] [--object-format=<format]
+    	  [--separate-git-dir <git dir>] [--object-format=<format>]
+    	  [-b <branch-name> | --initial-branch=<branch-name>]
     	  [--shared[=<permissions>]] [directory]
@@ Expand Down Expand Up / @@ -67,6 +68,12 @@ repository. @@
     +
     If this is reinitialization, the repository will be moved to the specified path.
+    -b <branch-name::
+    --initial-branch=<branch-name>::
+    Use the specified name for the initial branch in the newly created repository.
+    If not specified, fall back to the default name: `master`.
     --shared[=(false|true|umask|group|all|world|everybody|0xxx)]::
     Specify that the Git repository is to be shared amongst several users.  This
@@ Expand Down @@

-Original file line number
+Diff line change
@@ Expand Up / @@ -183,7 +183,7 @@ set-branch (-d|--default) [--] <path>:: @@
     	Sets the default remote tracking branch for the submodule. The
     	`--branch` option allows the remote branch to be specified. The
     	`--default` option removes the submodule.<name>.branch configuration
-    	key, which causes the tracking branch to default to 'master'.
+    	key, which causes the tracking branch to default to the remote 'HEAD'.
     set-url [--] <path> <newurl>::
     	Sets the URL of the specified submodule to <newurl>. Then, it will
@@ Expand Down Expand Up / @@ -284,7 +284,7 @@ OPTIONS @@
     	`.gitmodules` for `update --remote`.  A special value of `.` is used to
     	indicate that the name of the branch in the submodule should be the
     	same name as the current branch in the current repository.  If the
-    	option is not specified, it defaults to 'master'.
+    	option is not specified, it defaults to the remote 'HEAD'.
     -f::
     --force::
@@ Expand Down Expand Up / @@ -322,10 +322,10 @@ OPTIONS @@
     	the superproject's recorded SHA-1 to update the submodule, use the
     	status of the submodule's remote-tracking branch.  The remote used
     	is branch's remote (`branch.<name>.remote`), defaulting to `origin`.
-    	The remote branch used defaults to `master`, but the branch name may
-    	be overridden by setting the `submodule.<name>.branch` option in
-    	either `.gitmodules` or `.git/config` (with `.git/config` taking
-    	precedence).
+    	The remote branch used defaults to the remote `HEAD`, but the branch
+    	name may be overridden by setting the `submodule.<name>.branch`
+    	option in either `.gitmodules` or `.git/config` (with `.git/config`
+    	taking precedence).
     +
     This works for any of the supported update procedures (`--checkout`,
     `--rebase`, etc.).  The only change is the source of the target SHA-1.
@@ Expand Down @@

-Original file line number
+Diff line change
@@ Expand Up / @@ -49,9 +49,9 @@ submodule.<name>.update:: @@
     submodule.<name>.branch::
     	A remote branch name for tracking updates in the upstream submodule.
-    	If the option is not specified, it defaults to 'master'.  A special
-    	value of `.` is used to indicate that the name of the branch in the
-    	submodule should be the same name as the current branch in the
+    	If the option is not specified, it defaults to the remote 'HEAD'.
+    	A special value of `.` is used to indicate that the name of the branch
+    	in the submodule should be the same name as the current branch in the
     	current repository.  See the `--remote` documentation in
     	linkgit:git-submodule[1] for details.
@@ Expand Down @@

-Original file line number
+Diff line change
@@ Expand Up @@
     		}
     	}
-    	init_db(git_dir, real_git_dir, option_template, GIT_HASH_UNKNOWN, INIT_DB_QUIET);
+    	init_db(git_dir, real_git_dir, option_template, GIT_HASH_UNKNOWN, NULL,
+    		INIT_DB_QUIET);
     	if (real_git_dir)
     		git_dir = real_git_dir;
@@ Expand Down Expand Up @@
     		remote_head_points_at = NULL;
     		remote_head = NULL;
     		option_no_checkout = 1;
-    		if (!option_bare)
-    			install_branch_config(0, "master", option_origin,
-    					      "refs/heads/master");
+    		if (!option_bare) {
+    			const char *branch = git_default_branch_name();
+    			char *ref = xstrfmt("refs/heads/%s", branch);
+    			install_branch_config(0, branch, option_origin, ref);
+    			free(ref);
+    		}
     	}
     	write_refspec_config(src_ref_prefix, our_head_points_at,
@@ Expand Down @@

-Original file line number
+Diff line change
@@ Expand Up / @@ -203,6 +203,7 @@ void initialize_repository_version(int hash_algo) @@
     static int create_default_files(const char *template_path,
     				const char *original_git_dir,
+    				const char *initial_branch,
     				const struct repository_format *fmt)
     {
     	struct stat st1;
@@ Expand Down Expand Up @@
     		die("failed to set up refs db: %s", err.buf);
     	/*
-    	 * Create the default symlink from ".git/HEAD" to the "master"
-    	 * branch, if it does not exist yet.
+    	 * Point the HEAD symref to the initial branch with if HEAD does
+    	 * not yet exist.
     	 */
     	path = git_path_buf(&buf, "HEAD");
     	reinit = (!access(path, R_OK)
     		  || readlink(path, junk, sizeof(junk)-1) != -1);
     	if (!reinit) {
-    		if (create_symref("HEAD", "refs/heads/master", NULL) < 0)
+    		char *ref;
+    		if (!initial_branch)
+    			initial_branch = git_default_branch_name();
+    		ref = xstrfmt("refs/heads/%s", initial_branch);
+    		if (check_refname_format(ref, 0) < 0)
+    			die(_("invalid initial branch name: '%s'"),
+    			    initial_branch);
+    		if (create_symref("HEAD", ref, NULL) < 0)
     			exit(1);
+    		free(ref);
     	}
     	initialize_repository_version(fmt->hash_algo);
@@ Expand Down Expand Up @@
     }
     int init_db(const char *git_dir, const char *real_git_dir,
-    	    const char *template_dir, int hash, unsigned int flags)
+    	    const char *template_dir, int hash, const char *initial_branch,
+    	    unsigned int flags)
     {
     	int reinit;
     	int exist_ok = flags & INIT_DB_EXIST_OK;
@@ Expand Down Expand Up / @@ -425,7 +438,11 @@ int init_db(const char *git_dir, const char *real_git_dir, @@
     	validate_hash_algorithm(&repo_fmt, hash);
-    	reinit = create_default_files(template_dir, original_git_dir, &repo_fmt);
+    	reinit = create_default_files(template_dir, original_git_dir,
+    				      initial_branch, &repo_fmt);
+    	if (reinit && initial_branch)
+    		warning(_("re-init: ignored --initial-branch=%s"),
+    			initial_branch);
     	create_object_directory();
@@ Expand Down Expand Up @@
     	const char *template_dir = NULL;
     	unsigned int flags = 0;
     	const char *object_format = NULL;
+    	const char *initial_branch = NULL;
     	int hash_algo = GIT_HASH_UNKNOWN;
     	const struct option init_db_options[] = {
     		OPT_STRING(0, "template", &template_dir, N_("template-directory"),
@@ Expand All @@
     		OPT_BIT('q', "quiet", &flags, N_("be quiet"), INIT_DB_QUIET),
     		OPT_STRING(0, "separate-git-dir", &real_git_dir, N_("gitdir"),
     			   N_("separate git dir from working tree")),
+    		OPT_STRING('b', "initial-branch", &initial_branch, N_("name"),
+    			   N_("override the name of the initial branch")),
     		OPT_STRING(0, "object-format", &object_format, N_("hash"),
     			   N_("specify the hash algorithm to use")),
     		OPT_END()
@@ Expand Down Expand Up @@
     	UNLEAK(work_tree);
     	flags |= INIT_DB_EXIST_OK;
-    	return init_db(git_dir, real_git_dir, template_dir, hash_algo, flags);
+    	return init_db(git_dir, real_git_dir, template_dir, hash_algo,
+    		       initial_branch, flags);
     }

-Original file line number
+Diff line change
@@ Expand Up / @@ -451,10 +451,7 @@ static void fmt_merge_msg_title(struct strbuf *out, @@
     			strbuf_addf(out, " of %s", srcs.items[i].string);
     	}
-    	if (!strcmp("master", current_branch))
-    		strbuf_addch(out, '\n');
-    	else
-    		strbuf_addf(out, " into %s\n", current_branch);
+    	strbuf_addf(out, " into %s\n", current_branch);
     }
     static void fmt_tag_signature(struct strbuf *tagbuf,
@@ Expand Down @@

-Original file line number
+Diff line change
@@ Expand Up @@
     		argv_array_pushf(prefixes, *p, len, prefix);
     }
+    char *repo_default_branch_name(struct repository *r)
+    {
+    	const char *config_key = "init.defaultbranch";
+    	const char *config_display_key = "init.defaultBranch";
+    	char *ret = NULL, *full_ref;
+    	if (repo_config_get_string(r, config_key, &ret) < 0)
+    		die(_("could not retrieve `%s`"), config_display_key);
+    	if (!ret)
+    		ret = xstrdup("master");
+    	full_ref = xstrfmt("refs/heads/%s", ret);
+    	if (check_refname_format(full_ref, 0))
+    		die(_("invalid branch name: %s = %s"), config_display_key, ret);
+    	free(full_ref);
+    	return ret;
+    }
+    const char *git_default_branch_name(void)
+    {
+    	static char *ret;
+    	if (!ret)
+    		ret = repo_default_branch_name(the_repository);
+    	return ret;
+    }
     /*
      * *string and *len will only be substituted, and *string returned (for
      * later free()ing) if the string passed in is a magic short-hand form
@@ Expand Down @@

-Original file line number
+Diff line change
@@ Expand Up @@
     int dwim_ref(const char *str, int len, struct object_id *oid, char **ref);
     int dwim_log(const char *str, int len, struct object_id *oid, char **ref);
+    /*
+     * Retrieves the default branch name for newly-initialized repositories.
+     *
+     * The return value of `repo_default_branch_name()` is an allocated string. The
+     * return value of `git_default_branch_name()` is a singleton.
+     */
+    const char *git_default_branch_name(void);
+    char *repo_default_branch_name(struct repository *r);
     /*
      * A ref_transaction represents a collection of reference updates that
      * should succeed or fail together.
@@ Expand Down @@

-Original file line number
+Diff line change
@@ Expand Up / @@ -13,7 +13,7 @@ @@
     static const char *url;
     static int dump_from_file;
     static const char *private_ref;
-    static const char *remote_ref = "refs/heads/master";
+    static char *remote_ref;
     static const char *marksfilename, *notes_ref;
     struct rev_note { unsigned int rev_nr; };
@@ Expand Down Expand Up / @@ -286,14 +286,17 @@ int cmd_main(int argc, const char **argv) @@
     			private_ref_sb = STRBUF_INIT, marksfilename_sb = STRBUF_INIT,
     			notes_ref_sb = STRBUF_INIT;
     	static struct remote *remote;
-    	const char *url_in;
+    	const char *url_in, *remote_ref_short;
     	setup_git_directory();
     	if (argc < 2 || argc > 3) {
     		usage("git-remote-svn <remote-name> [<url>]");
     		return 1;
     	}
+    	remote_ref_short = git_default_branch_name();
+    	remote_ref = xstrfmt("refs/heads/%s", remote_ref_short);
     	remote = remote_get(argv[1]);
     	url_in = (argc == 3) ? argv[2] : remote->url[0];
@@ Expand All / @@ -306,7 +309,8 @@ int cmd_main(int argc, const char **argv) @@
     		url = url_sb.buf;
     	}
-    	strbuf_addf(&private_ref_sb, "refs/svn/%s/master", remote->name);
+    	strbuf_addf(&private_ref_sb, "refs/svn/%s/%s",
+    		    remote->name, remote_ref_short);
     	private_ref = private_ref_sb.buf;
     	strbuf_addf(&notes_ref_sb, "refs/notes/%s/revs", remote->name);
@@ Expand Down @@

-Original file line number
+Diff line change
@@ Expand Up / @@ -276,15 +276,15 @@ static void read_branches_file(struct remote *remote) @@
     	/*
     	 * The branches file would have URL and optionally
-    	 * #branch specified.  The "master" (or specified) branch is
+    	 * #branch specified.  The default (or specified) branch is
     	 * fetched and stored in the local branch matching the
     	 * remote name.
     	 */
     	frag = strchr(buf.buf, '#');
     	if (frag)
     		*(frag++) = '\0';
     	else
-    		frag = "master";
+    		frag = (char *)git_default_branch_name();
     	add_url_alias(remote, strbuf_detach(&buf, NULL));
     	strbuf_addf(&buf, "refs/heads/%s:refs/heads/%s",
@@ Expand Down Expand Up / @@ -2097,8 +2097,16 @@ struct ref *guess_remote_head(const struct ref *head, @@
     	if (head->symref)
     		return copy_ref(find_ref_by_name(refs, head->symref));
-    	/* If refs/heads/master could be right, it is. */
+    	/* If a remote branch exists with the default branch name, let's use it. */
     	if (!all) {
+    		char *ref = xstrfmt("refs/heads/%s", git_default_branch_name());
+    		r = find_ref_by_name(refs, ref);
+    		free(ref);
+    		if (r && oideq(&r->old_oid, &head->old_oid))
+    			return copy_ref(r);
+    		/* Fall back to the hard-coded historical default */
     		r = find_ref_by_name(refs, "refs/heads/master");
     		if (r && oideq(&r->old_oid, &head->old_oid))
     			return copy_ref(r);
@@ Expand Down @@

-Original file line number
+Diff line change
@@ Expand Up / @@ -406,7 +406,7 @@ int send_pack(struct send_pack_args *args, @@
     	if (!remote_refs) {
     		fprintf(stderr, "No refs in common and none specified; doing nothing.\n"
-    			"Perhaps you should specify a branch such as 'master'.\n");
+    			"Perhaps you should specify a branch.\n");
     		return 0;
     	}
     	if (args->atomic && !atomic_supported)
@@ Expand Down @@

Allow overriding the default name of the default branch #656

Uh oh!

Allow overriding the default name of the default branch #656

Uh oh!

Uh oh!

Diff view

Diff view

There are no files selected for viewing

gitgitgadget bot Jun 16, 2020

Choose a reason for hiding this comment

Uh oh!

gitgitgadget bot Jun 23, 2020

Choose a reason for hiding this comment

Uh oh!

gitgitgadget bot Jun 24, 2020

Choose a reason for hiding this comment

Uh oh!

gitgitgadget bot Jun 24, 2020

Choose a reason for hiding this comment

Uh oh!

gitgitgadget bot Jun 24, 2020

Choose a reason for hiding this comment

Uh oh!

gitgitgadget bot Jun 24, 2020

Choose a reason for hiding this comment

Uh oh!

gitgitgadget bot Jun 24, 2020

Choose a reason for hiding this comment

Uh oh!

gitgitgadget bot Jun 24, 2020

Choose a reason for hiding this comment

Uh oh!

gitgitgadget bot Jun 24, 2020

Choose a reason for hiding this comment

Uh oh!

gitgitgadget bot Jun 24, 2020

Choose a reason for hiding this comment

Uh oh!

gitgitgadget bot Jun 10, 2020

Choose a reason for hiding this comment

Uh oh!

gitgitgadget bot Jun 10, 2020

Choose a reason for hiding this comment

Uh oh!

gitgitgadget bot Jun 11, 2020

Choose a reason for hiding this comment

Uh oh!

gitgitgadget bot Jun 11, 2020

Choose a reason for hiding this comment

Uh oh!

gitgitgadget bot Jun 11, 2020

Choose a reason for hiding this comment

Uh oh!

gitgitgadget bot Jun 16, 2020

Choose a reason for hiding this comment

Uh oh!

gitgitgadget bot Jun 16, 2020

Choose a reason for hiding this comment

Uh oh!

gitgitgadget bot Jun 18, 2020

Choose a reason for hiding this comment

Uh oh!

gitgitgadget bot Jun 23, 2020

Choose a reason for hiding this comment

Uh oh!

gitgitgadget bot Jun 11, 2020

Choose a reason for hiding this comment

Uh oh!

gitgitgadget bot Jun 12, 2020

Choose a reason for hiding this comment

Uh oh!

gitgitgadget bot Jun 12, 2020

Choose a reason for hiding this comment

Uh oh!

gitgitgadget bot Jun 15, 2020

Choose a reason for hiding this comment

Uh oh!

gitgitgadget bot Jun 15, 2020

Choose a reason for hiding this comment

Uh oh!