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

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

[Garrett Cooper]

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.

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

[Jeff King]

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

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

[Garrett Cooper]

On Apr 2, 2013, at 10:23 AM, Jeff King <peff@peff.net> wrote:

> 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..

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

[Jeff King]

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

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

[Jeff King]

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

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

[Jeff King]

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

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

[Jeff King]

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

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

[Garrett Cooper]

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>

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

[Garrett Cooper]

On Tue, Apr 2, 2013 at 12:36 PM, Garrett Cooper <yaneurabeya@gmail.com> wrote:
> 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>

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

[Jeff King]

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

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

[Jeff King]

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

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

[Garrett Cooper]

On Tue, Apr 2, 2013 at 12:04 PM, Jeff King <peff@peff.net> 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 <peff@peff.net>

LGTM!

Reviewed-by: Garrett Cooper <yaneurabeya@gmail.com>

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

[Jeff King]

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

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

[Junio C Hamano]

Jeff King <peff@peff.net> writes:

> 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.

>> 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).

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

[Jonathan Nieder]

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