threads / bug / 33354

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

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

## tl;dr

15 messages between Apr 2, 2013 and Apr 2, 2013.

replies: 14people: 4as markdown or json

Garrett Cooper· Apr 2, 2013, 17:07 UTC · lore
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.
Jeff King· Apr 2, 2013, 17:23 UTC · re: Garrett Cooper · lore

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

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
Garrett Cooper· Apr 2, 2013, 17:30 UTC · re: Jeff King · lore

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

On Apr 2, 2013, at 10:23 AM, Jeff King <peff@peff.net> wrote:
Show 30 quoted lines
> 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.
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..
Jeff King· Apr 2, 2013, 17:51 UTC · re: Garrett Cooper · lore

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

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
Jeff King· Apr 2, 2013, 19:01 UTC · re: Jeff King · lore

[RFC/PATCH 0/5] branch --set-upstream-to error-message improvements

On Tue, Apr 02, 2013 at 01:51:13PM -0400, Jeff King wrote:
Show 5 quoted lines
> 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
Jeff King· Apr 2, 2013, 19:02 UTC · re: Jeff King · lore

[PATCH 1/5] t3200: test --set-upstream-to with bogus refs

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 <peff@peff.net>
---
 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
Jeff King· Apr 2, 2013, 19:03 UTC · re: Jeff King · lore

[PATCH 2/5] branch: factor out "upstream is not a branch" error messages

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 <peff@peff.net>
---
 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
Garrett Cooper· Apr 2, 2013, 19:36 UTC · re: Jeff King · lore

Re: [PATCH 2/5] branch: factor out "upstream is not a branch" error messages

On Tue, Apr 2, 2013 at 12:03 PM, Jeff King <peff@peff.net> wrote:
Show 9 quoted lines
>
> 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 <peff@peff.net>
LGTM!
Signed-off-by: Garrett Cooper <yaneurabeya@gmail.com>
Garrett Cooper· Apr 2, 2013, 19:36 UTC · re: Garrett Cooper · lore

Re: [PATCH 2/5] branch: factor out "upstream is not a branch" error messages

On Tue, Apr 2, 2013 at 12:36 PM, Garrett Cooper <yaneurabeya@gmail.com> wrote:
Show 14 quoted lines
> On Tue, Apr 2, 2013 at 12:03 PM, Jeff King <peff@peff.net> 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 <peff@peff.net>
>
> LGTM!
>
> Signed-off-by: Garrett Cooper <yaneurabeya@gmail.com>
Sorry, meant...
Reviewed-by: Garrett Cooper <yaneurabeya@gmail.com>
Jeff King· Apr 2, 2013, 19:04 UTC · re: Jeff King · lore

[PATCH 3/5] branch: improve error message for missing --set-upstream-to ref

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 <peff@peff.net>
---
 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
Jeff King· Apr 2, 2013, 19:04 UTC · re: Jeff King · lore

[PATCH 4/5] branch: mention start_name in set-upstream error messages

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 <peff@peff.net>
---
 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
Garrett Cooper· Apr 2, 2013, 19:39 UTC · re: Jeff King · lore

Re: [PATCH 4/5] branch: mention start_name in set-upstream error messages

On Tue, Apr 2, 2013 at 12:04 PM, Jeff King <peff@peff.net> wrote:
Show 11 quoted lines
> 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 <peff@peff.net>
LGTM!
Reviewed-by: Garrett Cooper <yaneurabeya@gmail.com>
Jeff King· Apr 2, 2013, 19:05 UTC · re: Jeff King · lore

[PATCH 5/5] branch: give advice when tracking start-point is missing

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 <peff@peff.net>
---
 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
Junio C Hamano· Apr 2, 2013, 21:50 UTC · re: Jeff King · lore

Re: [RFC/PATCH 0/5] branch --set-upstream-to error-message improvements

Jeff King <peff@peff.net> writes:
Show 13 quoted lines
> 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).

Yeah, I am uneasy about 5/5 for the same reason. Also I feel a bit uneasy about 1/5 as well.

Show 6 quoted lines
>> 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.
Could there be the third?
    3. She planned to create a branch after setting the
       configuration.

I think it is remote (no pun intended) possibility, and I may be worried about people's existing workflow too much (as usual).

Jonathan Nieder· Apr 2, 2013, 19:08 UTC · re: Garrett Cooper · lore

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

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

← back to recent threads