branch: add prefixes to new branch names#2202
Open
valeriyoann wants to merge 3 commits intogit:masterfrom
Open
branch: add prefixes to new branch names#2202valeriyoann wants to merge 3 commits intogit:masterfrom
valeriyoann wants to merge 3 commits intogit:masterfrom
Conversation
github-project-automation
bot
moved this to Todo
in Op-Amp Frequency Response and Applications Suite
Welcome to GitGitGadgetHi @valeriyoann, and welcome to GitGitGadget, the GitHub App to send patch series to the Git mailing list from GitHub Pull Requests. Please make sure that either:
You can CC potential reviewers by adding a footer to the PR description with the following syntax: NOTE: DO NOT copy/paste your CC list from a previous GGG PR's description, Also, it is a good idea to review the commit messages one last time, as the Git project expects them in a quite specific form:
It is in general a good idea to await the automated test ("Checks") in this Pull Request before contributing the patches, e.g. to avoid trivial issues such as unportable code. Contributing the patchesBefore you can contribute the patches, your GitHub username needs to be added to the list of permitted users. Any already-permitted user can do that, by adding a comment to your PR of the form Both the person who commented An alternative is the channel Once on the list of permitted usernames, you can contribute the patches to the Git mailing list by adding a PR comment If you want to see what email(s) would be sent for a After you submit, GitGitGadget will respond with another comment that contains the link to the cover letter mail in the Git mailing list archive. Please make sure to monitor the discussion in that thread and to address comments and suggestions (while the comments and suggestions will be mirrored into the PR by GitGitGadget, you will still want to reply via mail). If you do not want to subscribe to the Git mailing list just to be able to respond to a mail, you can download the mbox from the Git mailing list archive (click the curl -g --user "<EMailAddress>:<Password>" \
--url "imaps://imap.gmail.com/INBOX" -T /path/to/raw.txtTo iterate on your change, i.e. send a revised patch or patch series, you will first want to (force-)push to the same branch. You probably also want to modify your Pull Request description (or title). It is a good idea to summarize the revision by adding something like this to the cover letter (read: by editing the first comment on the PR, i.e. the PR description): To send a new iteration, just add another PR comment with the contents: Need help?New contributors who want advice are encouraged to join git-mentoring@googlegroups.com, where volunteers who regularly contribute to Git are willing to answer newbie questions, give advice, or otherwise provide mentoring to interested contributors. You must join in order to post or view messages, but anyone can join. You may also be able to find help in real time in the developer IRC channel, |
|
There is an issue in commit d47d061:
|
valeriyoann
force-pushed
the
branch-with-prefix
branch
2 times, most recently
from
c2f18f8 to
0124424
Compare
Member
|
/allow |
|
User valeriyoann is now allowed to use GitGitGadget. WARNING: valeriyoann has no public email address set on GitHub; GitGitGadget needs an email address to Cc: you on your contribution, so that you receive any feedback on the Git mailing list. Go to https://github.com/settings/profile to make your preferred email public to let GitGitGadget know which email address to use. |
Member
|
@valeriyoann you asked on IRC for help with the failing tests that you could not replicate locally. The failing tests run in the It is admittedly convoluted, thanks to Git's CI configuration, to see the actual error messages, I guess that the authors of the Here is the actually interesting part of the log: The leak error messagesThe reason for this is that the newly-added I suggest to add another |
Author
Thanks a lot for the /allow! And also thanks for the explanation, I indeed did not check other parts of the CI, only the steps that failed. |
valeriyoann
force-pushed
the
branch-with-prefix
branch
2 times, most recently
from
0178d02 to
30a6d8e
Compare
Author
|
/submit |
|
Submitted as pull.2202.git.git.1771574833967.gitgitgadget@gmail.com To fetch this version into To fetch this version to local tag |
|
Junio C Hamano wrote on the Git mailing list (how to reply to this email): "Yoann Valeri via GitGitGadget" <gitgitgadget@gmail.com> writes:
> From: VALERI Yoann <yoann.valeri@cea.fr>
>
> This patch adds a new configuration parameter for the branch creation
> feature: 'branch.addCurrentBranchAsPrefix'. When set to true, if one
We generally do not add a configuration variable before the concept
proves useful by being available as a command line option for some
time. Have we had a command line option that corresponds to this
feature for a year or two? Such a command line option will be
necessary even after we decide to add a configuration variable to
allow users to override the configured value per-invocation basis,
e.g., "git branch --no-current-branch-prefix maint-2.54 v2.54.0",
when you want to use the feature for most of your branches but want
to deviate from that convention in selected cases.
Thanks. |
|
Junio C Hamano wrote on the Git mailing list (how to reply to this email): By the way, the address at @cea.fr used as the author ident and for
sign-off seems to be bouncing, due to "550 mailbox unavailable".
Two requests:
* To the author of the patch. Could you make sure to sign-off with
reachable e-mail address? It cannot be helped that years after a
patch is written, the author may become unreachable, but we do
not want to see it happen even before we accept the patch.
* To GitGitGadget maintainers. Could you think about ways to catch
an incident like this, perhaps by sending a ping e-mail to first
time contributors to request response before allowing /submit or
something?
|
valeriyoann
force-pushed
the
branch-with-prefix
branch
3 times, most recently
from
03cccd9 to
0fbdf03
Compare
Author
|
/submit |
|
Submitted as pull.2202.v2.git.git.1772207333.gitgitgadget@gmail.com To fetch this version into To fetch this version to local tag |
![gitgitgadget-git[bot]](https://avatars.githubusercontent.com/in/46807?s=60&v=4){kind=small}
| @@ -713,7 +713,8 @@ int cmd_branch(int argc, | |||
| { | |||
There was a problem hiding this comment.
Junio C Hamano wrote on the Git mailing list (how to reply to this email):
"VALERI Yoann via GitGitGadget" <gitgitgadget@gmail.com> writes:
> From: VALERI Yoann <yoann.valeri@cea.fr>
>
> This patch adds a '--no-prefix' option to 'git branch' to selectively
> override the 'branch.addCurrentBranchAsPrefix' configuration parameter.
> Signed-off-by: VALERI Yoann <yoann.valeri@cea.fr>
> ---
That is unusual in multiple ways.
The usual way to do so is to give a command line option that is
usable without needing any configuration. This happens first in
early patches in a series.
And then, assuming that the command line option is widely supported
as useful (but cumbersome to specify every time), help the users by
adding a configuration variable, that can be overridden via the
command line option. That happens next in later patches in a
series.
And in order to help users discover these two features more easily,
it is customery to give them very similar names. In other words,
adding "--[no-]prefix-current-branch-name" may be more
understandable if it is added in patch [1/2], if we want to make the
matching configuration "branch.addCurrentBranchAsPrefix" in patch
[2/2].
Even better, have you considered leaving the door open for _others_
to come up with better ideas _later_ by making it extensible, e.g.,
--no-name-prefix
--name-prefix=<token>
where the initial implementation the only supported <token> is
"current" (to signal "current branch name")? That would mean that
the corresponding configuration variable would also be a string, not
a boolean, e.g., "branch.namePrefix = current".
Perhaps those who work with more than one remotes want to give their
branches meant to be pushed to remote A with prefix A- while naming
the branches meant to be pushed to remote B with prefix B-, or
something, that is not based on the current branch but something
else (e.g., @{push} in this hypothetical example). I am not saying
that you should add such a support to the feature in this series
(quite honestly, I am not convinced at all if prefixing with the
current branch name is even something worth adding myself), but we
do not want to end up with millions of branch.add${Foo}AsPrefix with
different values of ${Foo} when we discover that such prefixing
scheme is useful in the future.
Thanks.
This patch adds a '--name-prefix' option to add a prefix to a newly
created branch. It can use a regular string or a token as prefix. The
only token currently handled is '@{current}', which is substituted for
the current branch's name.
Signed-off-by: VALERI Yoann <yoann.valeri@cea.fr>
valeriyoann
force-pushed
the
branch-with-prefix
branch
from
0fbdf03 to
af9dbc8
Compare
This patch adds a new configuration parameter for the branch creation feature: 'branch.namePrefix'. It corresponds to the '--name-prefix' option of 'git branch' made as configuration parameter, and behaves exactly like it. Signed-off-by: VALERI Yoann <yoann.valeri@cea.fr>
This patch adds the '--no-name-prefix' option to prevent adding any prefix to the branch being created, whether through the '--name-prefix' option or the 'branch.namePrefix' configuration parameter. Signed-off-by: VALERI Yoann <yoann.valeri@cea.fr>
valeriyoann
force-pushed
the
branch-with-prefix
branch
from
af9dbc8 to
8f45374
Compare
|
H |
valeriyoann
changed the title
Author
|
/submit |
|
Submitted as pull.2202.v3.git.git.1772802872.gitgitgadget@gmail.com To fetch this version into To fetch this version to local tag |
|
Junio C Hamano wrote on the Git mailing list (how to reply to this email): "Yoann Valeri via GitGitGadget" <gitgitgadget@gmail.com> writes:
> This PR adds a way to add prefixes to a new branch being created. The goal
> is mostly to ease the developer process of creating new branches by adding
> shortcuts that can be set either with a command-line option or with
> configuration parameter. This is useful especially when you have to do
> similar backports on multiple branches, removing a bit of the need for
> finding names or typing the names over and over again.
>
> Changes since v1:
>
> * Added a '--no-prefix' option to git branch
>
> Changes since v2:
>
> * Changed the PR structure, with 3 patches:
> * first patch adds the '--name-prefix' option
> * second adds the 'branch.namePrefix' configuration parameter
> * third adds the '--no-name-prefix' option
> * Those patches only target 'git branch' now
I haven't read the actual patches, but the first step that adds
"--name-prefix" should also support "--no-name-prefix" at the same
time, with or without patches 2 and 3. Doing so would allow users
with an alias
[alias] bn = branch --name-prefix=blah
, who want to almost always add "blah" to their branches, to defeat
the prefix in rare occasions with
$ git bn --no-name-prefix foo
|
| @@ -713,7 +713,8 @@ int cmd_branch(int argc, | |||
| { | |||
There was a problem hiding this comment.
Junio C Hamano wrote on the Git mailing list (how to reply to this email):
"VALERI Yoann via GitGitGadget" <gitgitgadget@gmail.com> writes:
> - OPT_STRING(0, "name-prefix", &name_prefix, N_("name"), N_("prefix for the branch to create")),
> + OPT_STRING_F(0, "name-prefix", &name_prefix, N_("name"), N_("prefix for the branch to create"), PARSE_OPT_NONEG),
> + OPT_BOOL(0, "no-name-prefix", &no_name_prefix, N_("do not use any prefix for the branch to create")),
You do not want a separate "no-*" entry in the options[] table.
If we look at parse-options.c to see how OPTION_STRING is handled,
we find:
case OPTION_STRING:
if (unset)
*(const char **)opt->value = NULL;
else if (opt->flags & PARSE_OPT_OPTARG && !p->opt)
*(const char **)opt->value = (const char *)opt->defval;
else
return get_arg(p, opt, flags, (const char **)opt->value);
return 0;
which tells us
* "--no-name-prefix" is caught by "if (unset)" and causes the
name_prefix variable set to NULL.
* if we give OPT_OPTARG, we can allow "--name-prefix" (with no
parameter) to default to opt->defval value; this feature is not
very useful in our application.
* Otherwise we get the string after "--name-prefix=".
So you do not need to do anything strange. To correctly implement
the order of handling configuration and command line, you would do:
* initialize name_prefix to NULL. By default no name_prefix is
used.
* early in the cmd_branch() before you call parse_options(),
consult the configuration and pick up branch.nameprefix
and set it to name_prefix variable.
* then you call parse_options(). If the command line has
"--no-name-prefix", "if (unset)" kicks in and clears the
name_prefix variable pointed at by the opt->value. If the
command line has "--name-prefix=blah", the name_prefix variable,
which may have obtained a value from the configuration, is
overwritten with "blah". If the command line does not do
anything, then the name_prefix variable will retain whatever
value it got from the configuration.
|
Eric Sunshine wrote on the Git mailing list (how to reply to this email): On Fri, Mar 6, 2026 at 8:14 AM Yoann Valeri via GitGitGadget
<gitgitgadget@gmail.com> wrote:
> This PR adds a way to add prefixes to a new branch being created. The goal
> is mostly to ease the developer process of creating new branches by adding
> shortcuts that can be set either with a command-line option or with
> configuration parameter. This is useful especially when you have to do
> similar backports on multiple branches, removing a bit of the need for
> finding names or typing the names over and over again.
Sorry, but I'm having trouble understanding the value of this patch
series. Neither the cover letter nor the patches themselves provide
enough context to really understand how this feature would be helpful.
Adding some real-world examples of how this simplifies your workflow
*might* help sell the idea. Without such examples, it's difficult to
imagine that you can't achieve the same with some simple aliases or
tooling/scripting on your side.
My other concern is that this implementation is too special-case by
assuming that users will only want to apply the "special value" as a
prefix. It is easy to imagine some users instead wanting the special
value added as a suffix or embedded. As such, a (possibly) more
palatable implementation (assuming this feature is even desirable at
all) might be to instead allow the user to specify some sort of format
string into which the special value (or values) is interpolated. |
|
User |
| @@ -17,7 +17,8 @@ git branch [--color[=<when>] | --no-color] [--show-current] | |||
| [(-r|--remotes) | (-a|--all)] | |||
There was a problem hiding this comment.
Eric Sunshine wrote on the Git mailing list (how to reply to this email):
On Fri, Mar 6, 2026 at 8:15 AM VALERI Yoann via GitGitGadget
<gitgitgadget@gmail.com> wrote:
> This patch adds a '--name-prefix' option to add a prefix to a newly
> created branch. It can use a regular string or a token as prefix. The
> only token currently handled is '@{current}', which is substituted for
> the current branch's name.
>
> Signed-off-by: VALERI Yoann <yoann.valeri@cea.fr>
> ---
> diff --git a/Documentation/git-branch.adoc b/Documentation/git-branch.adoc
> @@ -64,6 +65,10 @@ Note that this will create the new branch, but it will not switch the
> +With a `--name-prefix` option, you can add a prefix to the branch to create.
> +This can either a simple name, or a token. Currently, only '@{current}' is
> +managed as token, and will use the current branch name as prefix.
s/This can/& be/
> diff --git a/branch.c b/branch.c
> @@ -365,6 +365,23 @@ int read_branch_desc(struct strbuf *buf, const char *branch_name)
> +void add_branch_prefix(const char *name_prefix,
> + const char *current_branch, struct strbuf *buf)
> +{
> + int value = 0;
What is `value`? It doesn't seem to be used at all in this function.
> + if (!name_prefix)
> + return;
> +
> + if (name_prefix[0] != '@') {
> + strbuf_addstr(buf, name_prefix);
> + return;
> + }
> +
> + if (strcmp(name_prefix, "@{current}") == 0)
> + strbuf_addstr(buf, current_branch);
> +}
I would expect this function to produce some sort of diagnostic
warning when the user has given it a "@{token}" it doesn't recognize.
> diff --git a/branch.h b/branch.h
> @@ -148,6 +148,18 @@ int install_branch_config(int flag, const char *local, const char *origin, const
> +/*
> + * Store in 'buf' a prefix to the name of a branch to create by using the given
> + * string 'name_prefix'. It can either be a simple string to a shorthand
> + * starting with '@'.
> + *
> + * Currently, only '@{current}' is managed, and will use 'current_branch' as
> + * prefix.
> + */
> +void add_branch_prefix(const char *name_prefix, const char *current_branch,
> + struct strbuf *buf);
It feels unnecessarily burdensome to force the caller to compute and
pass in `current_branch`. Intuitively, one would expect
add_branch_prefix() to compute the current branch itself if it
discovers that "@{current}" has been requested.
Moveover, this approach will not scale well when support for
additional "@{tokens}" is added down the road since it burdens *all*
callers with providing the values for *all* possible tokens.
> diff --git a/t/t3200-branch.sh b/t/t3200-branch.sh
> @@ -1716,4 +1716,22 @@ test_expect_success 'errors if given a bad branch name' '
> +test_expect_success 'create branch with --name-prefix' '
> + git config branch.autosetupmerge false &&
Let's use `test_config` which will ensure that this setting is
reverted at the end of the test.
> + git branch branch-with-prefix &&
> + git branch --name-prefix "blob" -- -with-prefix &&
> + test_must_fail git branch --name-prefix "blob" -- -with-prefix &&
> + git branch --name-prefix "@{current}" -- -with-prefix &&
> + git switch blob-with-prefix &&
> + git branch --name-prefix "@{current}" -- -with-prefix &&
> + test_must_fail git branch --name-prefix "@{current}" -- -with-prefix &&
> + test_ref_exists refs/heads/branch-with-prefix &&
> + test_ref_exists refs/heads/main-with-prefix &&
> + test_ref_exists refs/heads/blob-with-prefix &&
> + test_ref_exists refs/heads/blob-with-prefix-with-prefix &&
> + git checkout main &&
> + git branch -D branch-with-prefix main-with-prefix blob-with-prefix &&
> + git branch -D blob-with-prefix-with-prefix
> +'
| @@ -35,6 +35,11 @@ This option defaults to `never`. | |||
| value of this variable will be used as the default. | |||
There was a problem hiding this comment.
Eric Sunshine wrote on the Git mailing list (how to reply to this email):
On Fri, Mar 6, 2026 at 8:15 AM VALERI Yoann via GitGitGadget
<gitgitgadget@gmail.com> wrote:
> This patch adds a new configuration parameter for the branch creation
> feature: 'branch.namePrefix'. It corresponds to the '--name-prefix'
> option of 'git branch' made as configuration parameter, and behaves
> exactly like it.
>
> Signed-off-by: VALERI Yoann <yoann.valeri@cea.fr>
> ---
> diff --git a/Documentation/config/branch.adoc b/Documentation/config/branch.adoc
> @@ -35,6 +35,11 @@ This option defaults to `never`.
> +`branch.namePrefix`::
> + When a new branch is created with `git branch`, use the provided value as
> + prefix for its name. Can be '@{current}' to use the current branch's name
> + as prefix.
This probably ought to mention --[no]-name-prefix to let the user know
that the configuration value can be overridden.
> diff --git a/branch.c b/branch.c
> @@ -368,18 +368,22 @@ int read_branch_desc(struct strbuf *buf, const char *branch_name)
> void add_branch_prefix(const char *name_prefix,
> const char *current_branch, struct strbuf *buf)
> {
> - int value = 0;
> + char *config_prefix = NULL;
>
> - if (!name_prefix)
> - return;
> + if (!name_prefix) {
> + if (repo_config_get_string(the_repository, "branch.namePrefix",
> + &config_prefix))
> + return;
>
> - if (name_prefix[0] != '@') {
> - strbuf_addstr(buf, name_prefix);
> - return;
> + name_prefix = config_prefix;
> }
>
> - if (strcmp(name_prefix, "@{current}") == 0)
> + if (name_prefix[0] != '@')
> + strbuf_addstr(buf, name_prefix);
> + else if (strcmp(name_prefix, "@{current}") == 0)
> strbuf_addstr(buf, current_branch);
> +
> + free(config_prefix);
> }
This "diff" is very difficult to read because it's rewriting much of
the logic which was first introduced in patch [1/3]. When you reroll,
it would be a good idea to get the overall logic straight in patch
[1/3] so that subsequent patches only make small changes to it to
improve it (if necessary).
|
Junio C Hamano wrote on the Git mailing list (how to reply to this email): Eric Sunshine <sunshine@sunshineco.com> writes:
> Sorry, but I'm having trouble understanding the value of this patch
> series. Neither the cover letter nor the patches themselves provide
> enough context to really understand how this feature would be helpful.
> Adding some real-world examples of how this simplifies your workflow
> *might* help sell the idea. Without such examples, it's difficult to
> imagine that you can't achieve the same with some simple aliases or
> tooling/scripting on your side.
Very reasonable suggestion. Thanks. |
| @@ -17,7 +17,8 @@ git branch [--color[=<when>] | --no-color] [--show-current] | |||
| [(-r|--remotes) | (-a|--all)] | |||
There was a problem hiding this comment.
Junio C Hamano wrote on the Git mailing list (how to reply to this email):
"VALERI Yoann via GitGitGadget" <gitgitgadget@gmail.com> writes:
> diff --git a/Documentation/git-branch.adoc b/Documentation/git-branch.adoc
> index c0afddc424..00967fa758 100644
> --- a/Documentation/git-branch.adoc
> +++ b/Documentation/git-branch.adoc
> @@ -17,7 +17,8 @@ git branch [--color[=<when>] | --no-color] [--show-current]
> [(-r|--remotes) | (-a|--all)]
> [--list] [<pattern>...]
> git branch [--track[=(direct|inherit)] | --no-track] [-f]
> - [--recurse-submodules] <branch-name> [<start-point>]
> + [--recurse-submodules] [--name-prefix=<token>]
> + <branch-name> [<start-point>]
The indentation of the last line seems a bit off; the previous line
uses leading HT both in the original and in the updated version, but
the last line uses SP indent.
> @@ -64,6 +65,10 @@ Note that this will create the new branch, but it will not switch the
> working tree to it; use `git switch <new-branch>` to switch to the
> new branch.
>
> +With a `--name-prefix` option, you can add a prefix to the branch to create.
> +This can either a simple name, or a token. Currently, only '@{current}' is
> +managed as token, and will use the current branch name as prefix.
"can either" -> "can either be".
"managed" -> "supported".
> @@ -319,6 +324,10 @@ superproject's "origin/main", but tracks the submodule's "origin/main".
> and the object it points at. _<format>_ is the same as
> that of linkgit:git-for-each-ref[1].
>
> +`--name-prefix <token>`::
> + A string that will be used as prefix to the name of the new branch to
> + create. Can be '@{current}' to use the current branch's name.
> +
> _<branch-name>_::
> The name of the branch to create or delete.
> The new branch name must pass all checks defined by
> diff --git a/branch.c b/branch.c
> index 243db7d0fc..c24d7ce823 100644
> --- a/branch.c
> +++ b/branch.c
> @@ -365,6 +365,23 @@ int read_branch_desc(struct strbuf *buf, const char *branch_name)
> return 0;
> }
>
> +void add_branch_prefix(const char *name_prefix,
> + const char *current_branch, struct strbuf *buf)
Overly deep indentation here. Our tab-width is always 8, and you
would align the first "const char" on these two lines.
> +{
> + int value = 0;
Unused variable?
> + if (!name_prefix)
> + return;
> +
> + if (name_prefix[0] != '@') {
> + strbuf_addstr(buf, name_prefix);
> + return;
> + }
> +
> + if (strcmp(name_prefix, "@{current}") == 0)
> + strbuf_addstr(buf, current_branch);
> +}
What happens when we need to support more than the @{current}? Will
this function grow more parameters and the callers need to prepare
more parameters, even if only one of them may be picked by this
function? That does not smell like a sound way to make things
maintainable.
> diff --git a/builtin/branch.c b/builtin/branch.c
> index c577b5d20f..58631913c7 100644
> --- a/builtin/branch.c
> +++ b/builtin/branch.c
> ...
> + add_branch_prefix(name_prefix, start_name, &new_branch_name);
Here, `start_name` is passed as `current_branch` to `add_branch_prefix`.
However, `start_name` is the `<start-point>` (e.g., another branch,
a tag, or a commit). If the user runs:
$ git branch --name-prefix=@{current} new-branch other-branch
the prefix will be `other-branch` instead of the *current* branch
name as advertised in the documentation. It _may_ be how the
feature was intended to work, but then the name "current" and the
way the documentation describes the token are both misleading.
> + create_branch(the_repository, new_branch_name.buf, start_name,
> + force, 0, reflog, quiet, track, 0);
Overly deep indentation.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
3 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
This PR adds a way to add prefixes to a new branch being created. The goal is mostly to ease the developer process of creating new branches by adding shortcuts that can be set either with a command-line option or with configuration parameter. This is useful especially when you have to do similar backports on multiple branches, removing a bit of the need for finding names or typing the names over and over again.
Changes since v1:
Changes since v2:
cc: Patrick Steinhardt ps@pks.im
cc: Junio C Hamano gitster@pobox.com
cc: Yoann Valeri yoann.valeri@cea.fr
cc: Eric Sunshine sunshine@sunshineco.com