[PATCH] push: shorten "push.default is unset" warning message

From: Matthieu Moy <redacted>

The warning was purposely long, both to explain the situation properly
and to give a strong incentive to set push.default explicitly. This was
important before the 2.0 transition, and remained important for a while
after, so that new users get push.default explicitly in their
configuration and do not experience inconsistent behavior if they ever
used an older version of Git.

The warning has been there since version 1.8.0 (Oct 2012), hence we can
expect the vast majority of current Git users to have been exposed to
it, and most of them have already set push.default explicitly. The
switch from 'matching' to 'simple' was planned for 2.0 (May 2014), but
actually happened only for 2.3 (Feb 2015).

The warning is mostly seen by beginners, who have not set their
push.default configuration (yet). For many of them, the warning is
confusing because it talks about concepts that they have not learned and
asks them a choice that they are not able to make yet. See for example

  http://stackoverflow.com/questions/13148066/warning-push-default-is-unset-its-implicit-value-is-changing-in-git-2-0

(1260 votes for the question, 1824 for the answer as of writing)

Shorten the warning and mention only the way to remove the warning
without changing the behavior. Keep a pointer to the documentation so
that people willing to learn can still find the alternative behaviors
easily.

Eventually, the warning should be removed completely, but this can wait
a couple more releases or years.

Signed-off-by: Matthieu Moy <redacted>
---
 builtin/push.c | 20 +++-----------------
 1 file changed, 3 insertions(+), 17 deletions(-)

diff --git a/builtin/push.c b/builtin/push.c
index 960ffc3..00eba2f 100644
--- a/builtin/push.c
+++ b/builtin/push.c

@@ -205,26 +205,12 @@ static void setup_push_current(struct remote *remote, struct branch *branch)
 }
 
 static char warn_unspecified_push_default_msg[] =
-N_("push.default is unset; its implicit value has changed in\n"
-   "Git 2.0 from 'matching' to 'simple'. To squelch this message\n"
-   "and maintain the traditional behavior, use:\n"
-   "\n"
-   "  git config --global push.default matching\n"
-   "\n"
-   "To squelch this message and adopt the new behavior now, use:\n"
+N_("push.default is unset; its default value has changed in Git 2.0 from\n"
+   "'matching' to 'simple'. To squelch this message and adopt the new behavior, use:\n"
    "\n"
    "  git config --global push.default simple\n"
    "\n"
-   "When push.default is set to 'matching', git will push local branches\n"
-   "to the remote branches that already exist with the same name.\n"
-   "\n"
-   "Since Git 2.0, Git defaults to the more conservative 'simple'\n"
-   "behavior, which only pushes the current branch to the corresponding\n"
-   "remote branch that 'git pull' uses to update the current branch.\n"
-   "\n"
-   "See 'git help config' and search for 'push.default' for further information.\n"
-   "(the 'simple' mode was introduced in Git 1.7.11. Use the similar mode\n"
-   "'current' instead of 'simple' if you sometimes use older versions of Git)");
+   "See 'git help config' and search for 'push.default' for further information.");
 
 static void warn_unspecified_push_default_configuration(void)
 {

--

https://github.com/git/git/pull/201

From: "Matthieu Moy" <redacted>

From: Matthieu Moy <redacted>

The warning was purposely long, both to explain the situation properly
and to give a strong incentive to set push.default explicitly. This was
important before the 2.0 transition, and remained important for a while
after, so that new users get push.default explicitly in their
configuration and do not experience inconsistent behavior if they ever
used an older version of Git.

The warning has been there since version 1.8.0 (Oct 2012), hence we can
expect the vast majority of current Git users to have been exposed to
it, and most of them have already set push.default explicitly. The
switch from 'matching' to 'simple' was planned for 2.0 (May 2014), but
actually happened only for 2.3 (Feb 2015).

The warning is mostly seen by beginners, who have not set their
push.default configuration (yet). For many of them, the warning is
confusing because it talks about concepts that they have not learned and
asks them a choice that they are not able to make yet. See for example


http://stackoverflow.com/questions/13148066/warning-push-default-is-unset-its-implicit-value-is-changing-in-git-2-0

Shouldn't this also update the 'push' man page to state what the new default 
is. @gerry's comment to the top answer 
http://stackoverflow.com/a/13148313/717355 highlights that the word 'simple' 
is not even mentioned in the 'push' man page.

Junio and Peff both lean towards removing the message completely, and
I think I'm convinced. We would have to do this in the future anyway.

While we're there, improve the manual for git push as suggested by
Philip Oakley.

Matthieu Moy (2):
  push: remove "push.default is unset" warning message
  Documentation/git-push: document that 'simple' is the default

 Documentation/git-push.txt |  7 +++++++
 builtin/push.c             | 34 ----------------------------------
 2 files changed, 7 insertions(+), 34 deletions(-)

-- 
2.7.2.334.g35ed2ae.dirty

The warning was important before the 2.0 transition, and remained
important for a while after, so that new users get push.default
explicitly in their configuration and do not experience inconsistent
behavior if they ever used an older version of Git.

The warning has been there since version 1.8.0 (Oct 2012), hence we can
expect the vast majority of current Git users to have been exposed to
it, and most of them have already set push.default explicitly. The
switch from 'matching' to 'simple' was planned for 2.0 (May 2014), but
actually happened only for 2.3 (Feb 2015).

Today, the warning is mostly seen by beginners, who have not set their
push.default configuration (yet). For many of them, the warning is
confusing because it talks about concepts that they have not learned and
asks them a choice that they are not able to make yet. See for example

  http://stackoverflow.com/questions/13148066/warning-push-default-is-unset-its-implicit-value-is-changing-in-git-2-0

(1260 votes for the question, 1824 for the answer as of writing)

Remove the warning completely to avoid disturbing beginners. People who
still occasionally use an older version of Git will be exposed to the
warning through this old version.

Eventually, versions of Git without the warning will be deployed enough
and tutorials will not need to advise setting push.default anymore.

Signed-off-by: Matthieu Moy <redacted>
---
 builtin/push.c | 34 ----------------------------------
 1 file changed, 34 deletions(-)

diff --git a/builtin/push.c b/builtin/push.c
index 960ffc3..270db40 100644
--- a/builtin/push.c
+++ b/builtin/push.c

@@ -204,37 +204,6 @@ static void setup_push_current(struct remote *remote, struct branch *branch)
 	add_refspec(branch->name);
 }
 
-static char warn_unspecified_push_default_msg[] =
-N_("push.default is unset; its implicit value has changed in\n"
-   "Git 2.0 from 'matching' to 'simple'. To squelch this message\n"
-   "and maintain the traditional behavior, use:\n"
-   "\n"
-   "  git config --global push.default matching\n"
-   "\n"
-   "To squelch this message and adopt the new behavior now, use:\n"
-   "\n"
-   "  git config --global push.default simple\n"
-   "\n"
-   "When push.default is set to 'matching', git will push local branches\n"
-   "to the remote branches that already exist with the same name.\n"
-   "\n"
-   "Since Git 2.0, Git defaults to the more conservative 'simple'\n"
-   "behavior, which only pushes the current branch to the corresponding\n"
-   "remote branch that 'git pull' uses to update the current branch.\n"
-   "\n"
-   "See 'git help config' and search for 'push.default' for further information.\n"
-   "(the 'simple' mode was introduced in Git 1.7.11. Use the similar mode\n"
-   "'current' instead of 'simple' if you sometimes use older versions of Git)");
-
-static void warn_unspecified_push_default_configuration(void)
-{
-	static int warn_once;
-
-	if (warn_once++)
-		return;
-	warning("%s\n", _(warn_unspecified_push_default_msg));
-}
-
 static int is_workflow_triangular(struct remote *remote)
 {
 	struct remote *fetch_remote = remote_get(NULL);

@@ -253,9 +222,6 @@ static void setup_default_push_refspecs(struct remote *remote)
 		break;
 
 	case PUSH_DEFAULT_UNSPECIFIED:
-		warn_unspecified_push_default_configuration();
-		/* fallthru */
-
 	case PUSH_DEFAULT_SIMPLE:
 		if (triangular)
 			setup_push_current(remote, branch);

-- 
2.7.2.334.g35ed2ae.dirty

The default behavior is well documented already in git-config(1), but
git-push(1) itself did not mention it at all. For users willing to learn
how "git push" works but not how to configure it, this makes the
documentation cumbersome to read.

Make the git-push(1) page self-contained by adding a short summary of
what 'push.default=simple' does, early in the page.

Signed-off-by: Matthieu Moy <redacted>
---
 Documentation/git-push.txt | 7 +++++++
 1 file changed, 7 insertions(+)

diff --git a/Documentation/git-push.txt b/Documentation/git-push.txt
index 32482ce..a992793 100644
--- a/Documentation/git-push.txt
+++ b/Documentation/git-push.txt

@@ -37,6 +37,13 @@ the default `<refspec>` by consulting `remote.*.push` configuration,
 and if it is not found, honors `push.default` configuration to decide
 what to push (See linkgit:git-config[1] for the meaning of `push.default`).
 
+When neither the command-line nor the configuration specify what to
+push, the default behavior is used, which corresponds to the `simple`
+value for `push.default`: the current branch is pushed to the
+corresponding upstream branch, but as a safety measure, the push is
+aborted if the upstream branch does not have the same name as the
+local one.
+
 
 OPTIONS[[OPTIONS]]
 ------------------

-- 
2.7.2.334.g35ed2ae.dirty

On Thu, Feb 25, 2016 at 10:21:58AM +0100, Matthieu Moy wrote:

Junio and Peff both lean towards removing the message completely, and
I think I'm convinced. We would have to do this in the future anyway.

Unsurprisingly, this series looks good to me. :)

-Peff