[BUG] inconsistent behavior with --set-upstream vs --set-upstream-to

Hi!
	It looks like git branch --set-upstream-to doesn't function with 1.8.1.3 until I run --set-upstream. Is this a known bug?

root@fuji-current:/usr/src # git branch --set-upstream-to origin/pjdfstest-onefs pjdfstest-onefs
fatal: Not a valid object name: 'origin/pjdfstest-onefs'.
root@fuji-current:/usr/src # git branch --set-upstream origin/pjdfstest-onefs pjdfstest-onefs
The --set-upstream flag is deprecated and will be removed. Consider using --track or --set-upstream-to
Branch origin/pjdfstest-onefs set up to track local branch pjdfstest-onefs.
root@fuji-current:/usr/src # git branch --set-upstream-to origin/pjdfstest-onefs pjdfstest-onefs
Branch pjdfstest-onefs set up to track local branch origin/pjdfstest-onefs.
root@fuji-current:/usr/src # git --version
git version 1.8.1.3

Thanks!
-Garrett

PS Please CC me as I'm not subscribed to the list.

On Tue, Apr 02, 2013 at 10:07:01AM -0700, Garrett Cooper wrote:

	It looks like git branch --set-upstream-to doesn't function with 1.8.1.3 until I run --set-upstream. Is this a known bug?

No, but I do not think that is exactly what is going on.

root@fuji-current:/usr/src # git branch --set-upstream-to origin/pjdfstest-onefs pjdfstest-onefs
fatal: Not a valid object name: 'origin/pjdfstest-onefs'.

This is complaining that origin/pjdfstest-onefs does not actually exist
Does it? If the pjdfstest-onefs branch exists on the remote, do you need
to do a "git fetch" to make sure we have a local
refs/remotes/origin/pjdfstest-onefs tracking branch locally?

root@fuji-current:/usr/src # git branch --set-upstream origin/pjdfstest-onefs pjdfstest-onefs
The --set-upstream flag is deprecated and will be removed. Consider using --track or --set-upstream-to
Branch origin/pjdfstest-onefs set up to track local branch pjdfstest-onefs.

This did _not_ create the remote-tracking branch refs/remotes/origin/pjdfstest-onefs.
It created a new local branch called "origin/pjdfstest-onefs" (i.e.,
refs/heads/origin/pjdfstest-onefs), whose upstream is another local
branch "pjdfstest-onefs". That "backwards" order to the arguments is why
--set-upstream is deprecated; many people have made the same mistake.

root@fuji-current:/usr/src # git branch --set-upstream-to origin/pjdfstest-onefs pjdfstest-onefs
Branch pjdfstest-onefs set up to track local branch origin/pjdfstest-onefs.

Note how it says "local branch" here; you are not tracking anything at
the origin. You are tracking a local branch that happens to have
"origin/" in the name.

-Peff

On Apr 2, 2013, at 10:23 AM, Jeff King [off-list ref] wrote:

On Tue, Apr 02, 2013 at 10:07:01AM -0700, Garrett Cooper wrote:

quoted

   It looks like git branch --set-upstream-to doesn't function with 1.8.1.3 until I run --set-upstream. Is this a known bug?

No, but I do not think that is exactly what is going on.

quoted

root@fuji-current:/usr/src # git branch --set-upstream-to origin/pjdfstest-onefs pjdfstest-onefs
fatal: Not a valid object name: 'origin/pjdfstest-onefs'.

This is complaining that origin/pjdfstest-onefs does not actually exist
Does it? If the pjdfstest-onefs branch exists on the remote, do you need
to do a "git fetch" to make sure we have a local
refs/remotes/origin/pjdfstest-onefs tracking branch locally?

quoted

root@fuji-current:/usr/src # git branch --set-upstream origin/pjdfstest-onefs pjdfstest-onefs
The --set-upstream flag is deprecated and will be removed. Consider using --track or --set-upstream-to
Branch origin/pjdfstest-onefs set up to track local branch pjdfstest-onefs.

This did _not_ create the remote-tracking branch refs/remotes/origin/pjdfstest-onefs.
It created a new local branch called "origin/pjdfstest-onefs" (i.e.,
refs/heads/origin/pjdfstest-onefs), whose upstream is another local
branch "pjdfstest-onefs". That "backwards" order to the arguments is why
--set-upstream is deprecated; many people have made the same mistake.

quoted

root@fuji-current:/usr/src # git branch --set-upstream-to origin/pjdfstest-onefs pjdfstest-onefs
Branch pjdfstest-onefs set up to track local branch origin/pjdfstest-onefs.

Note how it says "local branch" here; you are not tracking anything at
the origin. You are tracking a local branch that happens to have
"origin/" in the name.

I push the branch to origin/ and then things tend to work, but since I obviously had been doing things wrong what's the correct order of operations for creating a branch and setting the upstream appropriately?

Thanks!
-Garrett

PS I love git as a tool, but I really wish the workflows were simpler or more straightforward, and error messages were clearer. It seems like this would help prevent usage errors like this..

On Tue, Apr 02, 2013 at 10:30:35AM -0700, Garrett Cooper wrote:

I push the branch to origin/ and then things tend to work, but since I
obviously had been doing things wrong what's the correct order of
operations for creating a branch and setting the upstream
appropriately?

Once you have pushed it, the push creates the refs/remotes/origin/foo
tracking branch automatically. You are then free to reference it
wherever you like, including in set-upstream-to. However, you can also
just ask push to do it for you with "--set-upstream" or "-u". So the
workflow is something like:

  $ git checkout -b my-topic
  $ hack hack hack
  $ git commit -m "looking good, time to publish"
  $ git push -u origin HEAD

PS I love git as a tool, but I really wish the workflows were simpler
or more straightforward, and error messages were clearer. It seems
like this would help prevent usage errors like this..

Things slowly improve as people make suggestions. I think the thing that
might have helped here is better advice when "set-upstream-to" is
pointed to a ref that does not exist.

Patches coming in a minute.

-Peff

On Tue, Apr 02, 2013 at 01:51:13PM -0400, Jeff King wrote:

Things slowly improve as people make suggestions. I think the thing that
might have helped here is better advice when "set-upstream-to" is
pointed to a ref that does not exist.

Patches coming in a minute.

Or 60 minutes. :)

I'm not decided on whether the last patch is overkill or not (or even if
it is not, whether it may end up confusing people who do not fit into
one of the slots it suggests).

  [1/5]: t3200: test --set-upstream-to with bogus refs
  [2/5]: branch: factor out "upstream is not a branch" error messages
  [3/5]: branch: improve error message for missing --set-upstream-to ref
  [4/5]: branch: mention start_name in set-upstream error messages
  [5/5]: branch: give advice when tracking start-point is missing

-Peff

These tests pass with the current code, but let's make sure
we don't accidentally break the behavior in the future.

Note that our tests expect failure when we try to set the
upstream to or from a missing branch. Technically we are
just munging config here, so we do not need the refs to
exist. But seeing that they do exist is a good check that
the user has not made a typo.

Signed-off-by: Jeff King <redacted>
---
 t/t3200-branch.sh | 12 ++++++++++++
 1 file changed, 12 insertions(+)

diff --git a/t/t3200-branch.sh b/t/t3200-branch.sh
index b08c9f2..09f65f8 100755
--- a/t/t3200-branch.sh
+++ b/t/t3200-branch.sh

@@ -409,6 +409,18 @@ test_expect_success '--set-upstream-to fails on detached HEAD' '
 	git checkout -
 '
 
+test_expect_success '--set-upstream-to fails on a missing dst branch' '
+	test_must_fail git branch --set-upstream-to master does-not-exist
+'
+
+test_expect_success '--set-upstream-to fails on a missing src branch' '
+	test_must_fail git branch --set-upstream-to does-not-exist master
+'
+
+test_expect_success '--set-upstream-to fails on a non-ref' '
+	test_must_fail git branch --set-upstream-to HEAD^{}
+'
+
 test_expect_success 'use --set-upstream-to modify HEAD' '
 	test_config branch.master.remote foo &&
 	test_config branch.master.merge foo &&

-- 
1.8.2.rc0.33.gd915649

This message is duplicated, and is quite long. Let's factor
it out, which avoids the repetition and the long lines. It
will also make future patches easier as we tweak the
message.

While we're at it, let's also mark it for translation.

Signed-off-by: Jeff King <redacted>
---
 branch.c | 7 +++++--
 1 file changed, 5 insertions(+), 2 deletions(-)

diff --git a/branch.c b/branch.c
index 2bef1e7..1acbd4e 100644
--- a/branch.c
+++ b/branch.c

@@ -197,6 +197,9 @@ int validate_new_branchname(const char *name, struct strbuf *ref,
 	return 1;
 }
 
+static const char upstream_not_branch[] =
+N_("Cannot setup tracking information; starting point is not a branch.");
+
 void create_branch(const char *head,
 		   const char *name, const char *start_name,
 		   int force, int reflog, int clobber_head,

@@ -231,14 +234,14 @@ void create_branch(const char *head,
 	case 0:
 		/* Not branching from any existing branch */
 		if (explicit_tracking)
-			die("Cannot setup tracking information; starting point is not a branch.");
+			die(_(upstream_not_branch));
 		break;
 	case 1:
 		/* Unique completion -- good, only if it is a real branch */
 		if (prefixcmp(real_ref, "refs/heads/") &&
 		    prefixcmp(real_ref, "refs/remotes/")) {
 			if (explicit_tracking)
-				die("Cannot setup tracking information; starting point is not a branch.");
+				die(_(upstream_not_branch));
 			else
 				real_ref = NULL;
 		}

-- 
1.8.2.rc0.33.gd915649

If we are trying to set the upstream config for a branch,
the create_branch function will check both that the name
resolves as a ref, and that it is either a local or
remote-tracking branch.

However, before we do so we run get_sha1 on it to find out
whether it resolves at all (since the create_branch function
is also used to create actual branches, it wants to know
where to start the new branch). This means that if you feed
a ref that does not exist to "branch --set-upstream-to",
rather than getting a helpful message about tracking, you
only get "not a valid object name".

Signed-off-by: Jeff King <redacted>
---
 branch.c | 7 ++++++-
 1 file changed, 6 insertions(+), 1 deletion(-)

diff --git a/branch.c b/branch.c
index 1acbd4e..060e9e3 100644
--- a/branch.c
+++ b/branch.c

@@ -199,6 +199,8 @@ N_("Cannot setup tracking information; starting point is not a branch.");
 
 static const char upstream_not_branch[] =
 N_("Cannot setup tracking information; starting point is not a branch.");
+static const char upstream_missing[] =
+N_("Cannot setup tracking information; starting point does not exist");
 
 void create_branch(const char *head,
 		   const char *name, const char *start_name,

@@ -227,8 +229,11 @@ void create_branch(const char *head,
 	}
 
 	real_ref = NULL;
-	if (get_sha1(start_name, sha1))
+	if (get_sha1(start_name, sha1)) {
+		if (explicit_tracking)
+			die(_(upstream_missing));
 		die("Not a valid object name: '%s'.", start_name);
+	}
 
 	switch (dwim_ref(start_name, strlen(start_name), sha1, &real_ref)) {
 	case 0:

-- 
1.8.2.rc0.33.gd915649

If we refuse a branch operation because the tracking
start_name the user gave us is bogus, we just print
something like:

 fatal: Cannot setup tracking information; start point is not a branch

If we mention the actual name we tried to use, that may help
the user figure out why it didn't work (e.g., if they gave
us the arguments in the wrong order).

Signed-off-by: Jeff King <redacted>
---
 branch.c | 10 +++++-----
 1 file changed, 5 insertions(+), 5 deletions(-)

diff --git a/branch.c b/branch.c
index 060e9e3..d6f4001 100644
--- a/branch.c
+++ b/branch.c

@@ -198,9 +198,9 @@ static const char upstream_missing[] =
 }
 
 static const char upstream_not_branch[] =
-N_("Cannot setup tracking information; starting point is not a branch.");
+N_("Cannot setup tracking information; starting point '%s' is not a branch.");
 static const char upstream_missing[] =
-N_("Cannot setup tracking information; starting point does not exist");
+N_("Cannot setup tracking information; starting point '%s' does not exist");
 
 void create_branch(const char *head,
 		   const char *name, const char *start_name,

@@ -231,7 +231,7 @@ void create_branch(const char *head,
 	real_ref = NULL;
 	if (get_sha1(start_name, sha1)) {
 		if (explicit_tracking)
-			die(_(upstream_missing));
+			die(_(upstream_missing), start_name);
 		die("Not a valid object name: '%s'.", start_name);
 	}
 

@@ -239,14 +239,14 @@ void create_branch(const char *head,
 	case 0:
 		/* Not branching from any existing branch */
 		if (explicit_tracking)
-			die(_(upstream_not_branch));
+			die(_(upstream_not_branch), start_name);
 		break;
 	case 1:
 		/* Unique completion -- good, only if it is a real branch */
 		if (prefixcmp(real_ref, "refs/heads/") &&
 		    prefixcmp(real_ref, "refs/remotes/")) {
 			if (explicit_tracking)
-				die(_(upstream_not_branch));
+				die(_(upstream_not_branch), start_name);
 			else
 				real_ref = NULL;
 		}

-- 
1.8.2.rc0.33.gd915649

If the user requests to --set-upstream-to a branch that does
not exist, then either:

  1. It was a typo.

  2. They thought the branch should exist.

In case (1), there is not much we can do beyond showing the
name we tried to use. For case (2), though, we can help to
guide them through common workflows.

Signed-off-by: Jeff King <redacted>
---
 advice.c |  2 ++
 advice.h |  1 +
 branch.c | 19 +++++++++++++++++--
 3 files changed, 20 insertions(+), 2 deletions(-)

diff --git a/advice.c b/advice.c
index 3bc8626..a8deee6 100644
--- a/advice.c
+++ b/advice.c

@@ -13,6 +13,7 @@ int advice_detached_head = 1;
 int advice_resolve_conflict = 1;
 int advice_implicit_identity = 1;
 int advice_detached_head = 1;
+int advice_set_upstream_failure = 1;
 
 static struct {
 	const char *name;

@@ -31,6 +32,7 @@ static struct {
 	{ "resolveconflict", &advice_resolve_conflict },
 	{ "implicitidentity", &advice_implicit_identity },
 	{ "detachedhead", &advice_detached_head },
+	{ "setupstreamfailure", &advice_set_upstream_failure },
 
 	/* make this an alias for backward compatibility */
 	{ "pushnonfastforward", &advice_push_update_rejected }

diff --git a/advice.h b/advice.h
index af0c983..94caa32 100644
--- a/advice.h
+++ b/advice.h

@@ -16,6 +16,7 @@ extern int advice_detached_head;
 extern int advice_resolve_conflict;
 extern int advice_implicit_identity;
 extern int advice_detached_head;
+extern int advice_set_upstream_failure;
 
 int git_default_advice_config(const char *var, const char *value);
 void advise(const char *advice, ...);

diff --git a/branch.c b/branch.c
index d6f4001..6ae6a4c 100644
--- a/branch.c
+++ b/branch.c

@@ -200,7 +200,16 @@ static const char upstream_missing[] =
 static const char upstream_not_branch[] =
 N_("Cannot setup tracking information; starting point '%s' is not a branch.");
 static const char upstream_missing[] =
-N_("Cannot setup tracking information; starting point '%s' does not exist");
+N_("the requested upstream branch '%s' does not exist");
+static const char upstream_advice[] =
+N_("\n"
+"If you are planning on basing your work on an upstream\n"
+"branch that already exists at the remote, you may need to\n"
+"run \"git fetch\" to retrieve it.\n"
+"\n"
+"If you are planning to push out a new local branch that\n"
+"will track its remote counterpart, you may want to use\n"
+"\"git push -u\" to set the upstream config as you push.");
 
 void create_branch(const char *head,
 		   const char *name, const char *start_name,

@@ -230,8 +239,14 @@ void create_branch(const char *head,
 
 	real_ref = NULL;
 	if (get_sha1(start_name, sha1)) {
-		if (explicit_tracking)
+		if (explicit_tracking) {
+			if (advice_set_upstream_failure) {
+				error(_(upstream_missing), start_name);
+				advise(_(upstream_advice));
+				exit(1);
+			}
 			die(_(upstream_missing), start_name);
+		}
 		die("Not a valid object name: '%s'.", start_name);
 	}
 

-- 
1.8.2.rc0.33.gd915649

Garrett Cooper wrote:

I push the branch to origin/ and then things tend to work, but since
I obviously had been doing things wrong what's the correct order of
operations for creating a branch and setting the upstream
appropriately?

git push -u origin pjdfstest-onefs

Thanks for a useful example,
Jonathan

On Tue, Apr 2, 2013 at 12:03 PM, Jeff King [off-list ref] wrote:

This message is duplicated, and is quite long. Let's factor
it out, which avoids the repetition and the long lines. It
will also make future patches easier as we tweak the
message.

While we're at it, let's also mark it for translation.

Signed-off-by: Jeff King <redacted>

LGTM!

Signed-off-by: Garrett Cooper <redacted>

On Tue, Apr 2, 2013 at 12:36 PM, Garrett Cooper [off-list ref] wrote:

On Tue, Apr 2, 2013 at 12:03 PM, Jeff King [off-list ref] wrote:

quoted

This message is duplicated, and is quite long. Let's factor
it out, which avoids the repetition and the long lines. It
will also make future patches easier as we tweak the
message.

While we're at it, let's also mark it for translation.

Signed-off-by: Jeff King <redacted>

LGTM!

Signed-off-by: Garrett Cooper <redacted>

Sorry, meant...

Reviewed-by: Garrett Cooper <redacted>

On Tue, Apr 2, 2013 at 12:04 PM, Jeff King [off-list ref] wrote:

If we refuse a branch operation because the tracking
start_name the user gave us is bogus, we just print
something like:

 fatal: Cannot setup tracking information; start point is not a branch

If we mention the actual name we tried to use, that may help
the user figure out why it didn't work (e.g., if they gave
us the arguments in the wrong order).

Signed-off-by: Jeff King <redacted>

LGTM!

Reviewed-by: Garrett Cooper <redacted>