Running 'git pull' from an unnamed branch

Running 'git pull' from an unnamed branch

[Reece Dunn]

Hi,

Here is something I have just recently tripped up on.

$ git pull
You asked me to pull without telling me which branch you
want to merge with, and 'branch..merge' in
your configuration file does not tell me either.  Please
name which branch you want to merge on the command line and
try again (e.g. 'git pull <repository> <refspec>').
See git-pull(1) for details on the refspec.

If you often merge with the same branch, you may want to
configure the following variables in your configuration
file:

    branch..remote = <nickname>
    branch..merge = <remote-ref>
    remote.<nickname>.url = <url>
    remote.<nickname>.fetch = <refspec>

See git-config(1) for details.

$ git branch
* (no branch)
  master

Running `git checkout master && git pull` fixed the above issue. The
patch below improves the error message for users that are in this
state.

Also, is "branch..remote" valid? Should this be "branch.remote"?

- Reece

>From c3933ba95f705dae1a41cb2ee6a282f3be0a6ab0 Mon Sep 17 00:00:00 2001
From: Reece Dunn <msclrhd@gmail.com>
Date: Sun, 5 Apr 2009 22:27:10 +0100
Subject: [PATCH] Improve the message when pulling to a headless branch.

---
 git-pull.sh |    4 ++++
 1 files changed, 4 insertions(+), 0 deletions(-)

diff --git a/git-pull.sh b/git-pull.sh
index 8a26763..00a72dd 100755
--- a/git-pull.sh
+++ b/git-pull.sh
@@ -97,6 +97,10 @@ error_on_no_merge_candidates () {
 	echo "try again (e.g. 'git pull <repository> <refspec>')."
 	echo "See git-pull(1) for details on the refspec."
 	echo
+	echo "You may not be on a branch. In this case, you need to move"
+	echo "onto the branch you want to pull to (usually master):"
+	echo "    git checkout <branch>"
+	echo
 	echo "If you often merge with the same branch, you may want to"
 	echo "configure the following variables in your configuration"
 	echo "file:"
-- 
1.6.0.4

Re: Running 'git pull' from an unnamed branch

[Sverre Rabbelier]

Heya,

On Sun, Apr 5, 2009 at 23:33, Reece Dunn <msclrhd@googlemail.com> wrote:
> +       echo "You may not be on a branch. In this case, you need to move"
> +       echo "onto the branch you want to pull to (usually master):"
> +       echo "    git checkout <branch>"
> +       echo

Please, there's already 17 lines of spam each time I type 'git pull',
let's not embed the entire user manual!

-- 
Cheers,

Sverre Rabbelier

Re: Running 'git pull' from an unnamed branch

[Markus Heidelberg]

Reece Dunn, 05.04.2009:
> Hi,
> 
> Here is something I have just recently tripped up on.
> 
> $ git pull
> 
> [..]
> 
> $ git branch
> * (no branch)
>   master
> 
> Running `git checkout master && git pull` fixed the above issue. The
> patch below improves the error message for users that are in this
> state.
> 
> Also, is "branch..remote" valid? Should this be "branch.remote"?

The current branch has no name, so there is nothing between the two
dots. For clarification: branch.(no branch).remote

> +	echo "You may not be on a branch. In this case, you need to move"
> +	echo "onto the branch you want to pull to (usually master):"
> +	echo "    git checkout <branch>"
> +	echo

Not being on a branch is not the general case when you receive this
message. Maybe determining if you are not on a branch and adjusting the
message acordingly is an option.

Markus

Re: Running 'git pull' from an unnamed branch

[Björn Steinbrink]

On 2009.04.05 22:33:57 +0100, Reece Dunn wrote:
> $ git pull
> You asked me to pull without telling me which branch you
> want to merge with, and 'branch..merge' in
> your configuration file does not tell me either.  Please
> name which branch you want to merge on the command line and
> try again (e.g. 'git pull <repository> <refspec>').
> See git-pull(1) for details on the refspec.
> 
> If you often merge with the same branch, you may want to
> configure the following variables in your configuration
> file:
> 
>     branch..remote = <nickname>
>     branch..merge = <remote-ref>
>     remote.<nickname>.url = <url>
>     remote.<nickname>.fetch = <refspec>
> 
> See git-config(1) for details.
> 
> $ git branch
> * (no branch)
>   master
> 
> Running `git checkout master && git pull` fixed the above issue. The
> patch below improves the error message for users that are in this
> state.

It doesn't "fix" anything, you're simply doing something different.

"git pull" while on a detached HEAD can't work, there are no defaults
that could be used. But e.g. "git pull origin master" would do, fetching
"master" from "origin" and merging it to the commit you have checked
out.

Your "git checkout master && git pull" does something else. It uses the
configured pull defaults for "master" to fetch something and merge it to
"master".

> Also, is "branch..remote" valid? Should this be "branch.remote"?

That's a bug, but it should not be branch.remote. The config setting is
branch.<name>.remote. As you were on a detached HEAD, there is no
"<name>", and the code that generates the error message doesn't handle
that correctly. I'd even say that in this case, the whole "If you often
merge ..." part makes no sense at all, you simply can't setup pull
defaults for a detached HEAD.

> +	echo "You may not be on a branch. In this case, you need to move"
> +	echo "onto the branch you want to pull to (usually master):"

Hm? Neither do you really need to move to a branch, nor is "master"
really _that_ special that it is warranted to recommend checking it
out... IMHO.

Björn

Re: Running 'git pull' from an unnamed branch

[Reece Dunn]

2009/4/5 Markus Heidelberg <markus.heidelberg@web.de>:
> Reece Dunn, 05.04.2009:
>> Hi,
>>
>> Here is something I have just recently tripped up on.
>>
>> $ git pull
>>
>> [..]
>>
>> $ git branch
>> * (no branch)
>>   master
>>
>> Running `git checkout master && git pull` fixed the above issue. The
>> patch below improves the error message for users that are in this
>> state.
>>
>> Also, is "branch..remote" valid? Should this be "branch.remote"?
>
> The current branch has no name, so there is nothing between the two
> dots. For clarification: branch.(no branch).remote

Ok. I see now.

>> +     echo "You may not be on a branch. In this case, you need to move"
>> +     echo "onto the branch you want to pull to (usually master):"
>> +     echo "    git checkout <branch>"
>> +     echo
>
> Not being on a branch is not the general case when you receive this
> message. Maybe determining if you are not on a branch and adjusting the
> message acordingly is an option.

So, something like:

From 59e8b71be1585a3a6c8c1233811c19ef0022b3e5 Mon Sep 17 00:00:00 2001
From: Reece Dunn <msclrhd@gmail.com>
Date: Sun, 5 Apr 2009 23:15:03 +0100
Subject: [PATCH] Improve the message when pulling to a headless branch.

---
 git-pull.sh |   40 +++++++++++++++++++++++-----------------
 1 files changed, 23 insertions(+), 17 deletions(-)

diff --git a/git-pull.sh b/git-pull.sh
index 8a26763..f263c04 100755
--- a/git-pull.sh
+++ b/git-pull.sh
@@ -90,23 +90,29 @@ error_on_no_merge_candidates () {

 	curr_branch=${curr_branch#refs/heads/}

-	echo "You asked me to pull without telling me which branch you"
-	echo "want to merge with, and 'branch.${curr_branch}.merge' in"
-	echo "your configuration file does not tell me either.  Please"
-	echo "name which branch you want to merge on the command line and"
-	echo "try again (e.g. 'git pull <repository> <refspec>')."
-	echo "See git-pull(1) for details on the refspec."
-	echo
-	echo "If you often merge with the same branch, you may want to"
-	echo "configure the following variables in your configuration"
-	echo "file:"
-	echo
-	echo "    branch.${curr_branch}.remote = <nickname>"
-	echo "    branch.${curr_branch}.merge = <remote-ref>"
-	echo "    remote.<nickname>.url = <url>"
-	echo "    remote.<nickname>.fetch = <refspec>"
-	echo
-	echo "See git-config(1) for details."
+	if [ -n "$curr_branch" ]; then
+		echo "You asked me to pull without telling me which branch you"
+		echo "want to merge with, and 'branch.${curr_branch}.merge' in"
+		echo "your configuration file does not tell me either.  Please"
+		echo "name which branch you want to merge on the command line"
+		echo "and try again (e.g. 'git pull <repository> <refspec>')."
+		echo "See git-pull(1) for details on the refspec."
+		echo
+		echo "If you often merge with the same branch, you may want to"
+		echo "configure the following variables in your configuration"
+		echo "file:"
+		echo
+		echo "    branch.${curr_branch}.remote = <nickname>"
+		echo "    branch.${curr_branch}.merge = <remote-ref>"
+		echo "    remote.<nickname>.url = <url>"
+		echo "    remote.<nickname>.fetch = <refspec>"
+		echo
+		echo "See git-config(1) for details."
+	else
+		echo "You may not be on a branch. In this case, you need to"
+		echo "move to the branch you want to pull to (usually master):"
+		echo "    git checkout <branch>"
+	fi
 	exit 1
 }

-- 
1.6.2.2.414.g81aa.dirty

Re: Running 'git pull' from an unnamed branch

[Markus Heidelberg]

Reece Dunn, 06.04.2009:
> 2009/4/5 Markus Heidelberg <markus.heidelberg@web.de>:
> > Reece Dunn, 05.04.2009:
> >> +     echo "You may not be on a branch. In this case, you need to move"
> >> +     echo "onto the branch you want to pull to (usually master):"
> >> +     echo "    git checkout <branch>"
> >> +     echo
> >
> > Not being on a branch is not the general case when you receive this
> > message. Maybe determining if you are not on a branch and adjusting the
> > message acordingly is an option.
> 
> So, something like:

>  git-pull.sh |   40 +++++++++++++++++++++++-----------------
>  1 files changed, 23 insertions(+), 17 deletions(-)
> 
> diff --git a/git-pull.sh b/git-pull.sh
> index 8a26763..f263c04 100755
> --- a/git-pull.sh
> +++ b/git-pull.sh
> @@ -90,23 +90,29 @@ error_on_no_merge_candidates () {
> 
>  	curr_branch=${curr_branch#refs/heads/}
> 
> -	echo "You asked me to pull without telling me which branch you"
> -	echo "want to merge with, and 'branch.${curr_branch}.merge' in"
> -	echo "your configuration file does not tell me either.  Please"
> -	echo "name which branch you want to merge on the command line and"
> -	echo "try again (e.g. 'git pull <repository> <refspec>')."
> -	echo "See git-pull(1) for details on the refspec."
> -	echo
> -	echo "If you often merge with the same branch, you may want to"
> -	echo "configure the following variables in your configuration"
> -	echo "file:"
> -	echo
> -	echo "    branch.${curr_branch}.remote = <nickname>"
> -	echo "    branch.${curr_branch}.merge = <remote-ref>"
> -	echo "    remote.<nickname>.url = <url>"
> -	echo "    remote.<nickname>.fetch = <refspec>"
> -	echo
> -	echo "See git-config(1) for details."
> +	if [ -n "$curr_branch" ]; then
> +		echo "You asked me to pull without telling me which branch you"
> +		echo "want to merge with, and 'branch.${curr_branch}.merge' in"
> +		echo "your configuration file does not tell me either.  Please"
> +		echo "name which branch you want to merge on the command line"
> +		echo "and try again (e.g. 'git pull <repository> <refspec>')."
> +		echo "See git-pull(1) for details on the refspec."
> +		echo
> +		echo "If you often merge with the same branch, you may want to"
> +		echo "configure the following variables in your configuration"
> +		echo "file:"
> +		echo
> +		echo "    branch.${curr_branch}.remote = <nickname>"
> +		echo "    branch.${curr_branch}.merge = <remote-ref>"
> +		echo "    remote.<nickname>.url = <url>"
> +		echo "    remote.<nickname>.fetch = <refspec>"
> +		echo
> +		echo "See git-config(1) for details."
> +	else
> +		echo "You may not be on a branch. In this case, you need to"
> +		echo "move to the branch you want to pull to (usually master):"
> +		echo "    git checkout <branch>"
> +	fi
>  	exit 1
>  }
> 

Yes, on something like this I thought, but the proposed solution is not
the right thing to do, see the response from Björn.

Maybe something like "You are not on a branch, so there cannot be a
configuration for git-pull. You have to explicitly tell the repository
and refspec." or so.

Markus

Re: Running 'git pull' from an unnamed branch

[Reece Dunn]

2009/4/5 Björn Steinbrink <B.Steinbrink@gmx.de>:
> On 2009.04.05 22:33:57 +0100, Reece Dunn wrote:
>> Running `git checkout master && git pull` fixed the above issue. The
>> patch below improves the error message for users that are in this
>> state.
>
> It doesn't "fix" anything, you're simply doing something different.
>
> "git pull" while on a detached HEAD can't work, there are no defaults
> that could be used. But e.g. "git pull origin master" would do, fetching
> "master" from "origin" and merging it to the commit you have checked
> out.

Sure.

> Your "git checkout master && git pull" does something else. It uses the
> configured pull defaults for "master" to fetch something and merge it to
> "master".

The two cases depend on if you want to stay with the detached HEAD or not.

>> Also, is "branch..remote" valid? Should this be "branch.remote"?
>
> That's a bug, but it should not be branch.remote. The config setting is
> branch.<name>.remote. As you were on a detached HEAD, there is no
> "<name>", and the code that generates the error message doesn't handle
> that correctly. I'd even say that in this case, the whole "If you often
> merge ..." part makes no sense at all, you simply can't setup pull
> defaults for a detached HEAD.

Yup. In my revised patch, I have it displaying a different message
(the one I added) instead of the default one you get at the moment.

>> +     echo "You may not be on a branch. In this case, you need to move"
>> +     echo "onto the branch you want to pull to (usually master):"
>
> Hm? Neither do you really need to move to a branch, nor is "master"
> really _that_ special that it is warranted to recommend checking it
> out... IMHO.

I said "usually master" to give a hint to the casual/newbie user. The
exact wording that is outputted in this case can be figured out. It
can also mention the case you highlighted.

- Reece

Re: Running 'git pull' from an unnamed branch

[Junio C Hamano]

Reece Dunn <msclrhd@googlemail.com> writes:

> diff --git a/git-pull.sh b/git-pull.sh
> index 8a26763..00a72dd 100755
> --- a/git-pull.sh
> +++ b/git-pull.sh
> @@ -97,6 +97,10 @@ error_on_no_merge_candidates () {
>  	echo "try again (e.g. 'git pull <repository> <refspec>')."
>  	echo "See git-pull(1) for details on the refspec."
>  	echo
> +	echo "You may not be on a branch. In this case, you need to move"
> +	echo "onto the branch you want to pull to (usually master):"
> +	echo "    git checkout <branch>"
> +	echo

I do not think that is necessarily what the user wanted to hear.  Often I
create trial merges on a detached HEAD when I hear a pull-request from
others (I have a few work trees that share the repository with my primary
working area, made with contrib/workdir/git-new-workdir script, and their
HEAD are typically detached at the tip of the master), and in such a use
case, the first line of the instruction in the context in your patch is
the right thing to give.  I do not want to have the resulting trial merge
anywhere on my real branches, and do not want to be told to switch to any
of them.

We really should teach people, especially the new ones early on, that "git
push" and "git pull" are meant to be told where-to/from and what, and how
to drive these commands with explicit arguments, before letting them rely
on the default configuration blindly without understanding the underlying
concepts.

The automation given by the configuration variables is certainly nice, and
the default created by "clone", "remote add" and "checkout -b" (with its
implicit "track") may make them simpler to operate for every day life, but
there is a limit.  Working on a detached HEAD is an ultimate free-form
hacking, and you do not even necessarily _want_ to have a "while my HEAD
is detached, please always do this" default configured.

Re: Running 'git pull' from an unnamed branch

[Reece Dunn]

2009/4/6 Junio C Hamano <gitster@pobox.com>:
> Reece Dunn <msclrhd@googlemail.com> writes:
>
>> diff --git a/git-pull.sh b/git-pull.sh
>> index 8a26763..00a72dd 100755
>> --- a/git-pull.sh
>> +++ b/git-pull.sh
>> @@ -97,6 +97,10 @@ error_on_no_merge_candidates () {
>>       echo "try again (e.g. 'git pull <repository> <refspec>')."
>>       echo "See git-pull(1) for details on the refspec."
>>       echo
>> +     echo "You may not be on a branch. In this case, you need to move"
>> +     echo "onto the branch you want to pull to (usually master):"
>> +     echo "    git checkout <branch>"
>> +     echo
>
> I do not think that is necessarily what the user wanted to hear.  Often I
> create trial merges on a detached HEAD when I hear a pull-request from
> others (I have a few work trees that share the repository with my primary
> working area, made with contrib/workdir/git-new-workdir script, and their
> HEAD are typically detached at the tip of the master), and in such a use
> case, the first line of the instruction in the context in your patch is
> the right thing to give.  I do not want to have the resulting trial merge
> anywhere on my real branches, and do not want to be told to switch to any
> of them.
>
> We really should teach people, especially the new ones early on, that "git
> push" and "git pull" are meant to be told where-to/from and what, and how
> to drive these commands with explicit arguments, before letting them rely
> on the default configuration blindly without understanding the underlying
> concepts.

Ok, so how about something like:

"You may not be on a branch. Because of this, you need to specify
where you are pulling from and to. See git-pull(1) for how to do this.
Alternatively, you can move to a named branch using:
    git checkout <branch>"

> The automation given by the configuration variables is certainly nice, and
> the default created by "clone", "remote add" and "checkout -b" (with its
> implicit "track") may make them simpler to operate for every day life, but
> there is a limit.  Working on a detached HEAD is an ultimate free-form
> hacking, and you do not even necessarily _want_ to have a "while my HEAD
> is detached, please always do this" default configured.

How about the above wording? I have kept the moving to a named branch,
but have made it optional and secondary to using git pull with
arguments. This supports the workflow you and others have described,
while retaining the hint for when you don't want to work on a detached
HEAD - for example, after running bisect - without saying that the
latter is required.

- Reece

Re: Running 'git pull' from an unnamed branch

[Björn Steinbrink]

On 2009.04.06 08:42:16 +0100, Reece Dunn wrote:
> 2009/4/6 Junio C Hamano <gitster@pobox.com>:
> > Reece Dunn <msclrhd@googlemail.com> writes:
> >
> >> diff --git a/git-pull.sh b/git-pull.sh
> >> index 8a26763..00a72dd 100755
> >> --- a/git-pull.sh
> >> +++ b/git-pull.sh
> >> @@ -97,6 +97,10 @@ error_on_no_merge_candidates () {
> >>       echo "try again (e.g. 'git pull <repository> <refspec>')."
> >>       echo "See git-pull(1) for details on the refspec."
> >>       echo
> >> +     echo "You may not be on a branch. In this case, you need to move"
> >> +     echo "onto the branch you want to pull to (usually master):"
> >> +     echo "    git checkout <branch>"
> >> +     echo
> >
> > I do not think that is necessarily what the user wanted to hear.  Often I
> > create trial merges on a detached HEAD when I hear a pull-request from
> > others (I have a few work trees that share the repository with my primary
> > working area, made with contrib/workdir/git-new-workdir script, and their
> > HEAD are typically detached at the tip of the master), and in such a use
> > case, the first line of the instruction in the context in your patch is
> > the right thing to give.  I do not want to have the resulting trial merge
> > anywhere on my real branches, and do not want to be told to switch to any
> > of them.
> >
> > We really should teach people, especially the new ones early on, that "git
> > push" and "git pull" are meant to be told where-to/from and what, and how
> > to drive these commands with explicit arguments, before letting them rely
> > on the default configuration blindly without understanding the underlying
> > concepts.
> 
> Ok, so how about something like:
> 
> "You may not be on a branch. Because of this, you need to specify

This should not say "may", either you are or you are not on a detached
HEAD, and git can tell that, so it should not let the user have to
guess.

> where you are pulling from and to. See git-pull(1) for how to do this.
> Alternatively, you can move to a named branch using:
>     git checkout <branch>"

Checking out a named branch won't solve the "problem" on its own.
Consider this:

git checkout origin/foo
   *do stuff*

git pull
   *Oh! I need a named branch*

git checkout -b foo
git pull
   *Still fails*

Maybe:
You asked me to pull without telling me which branch you want to merge
with and as you have no branch checked out, I cannot look for any
defaults to use. Please name which branch you want to merge on the
command line and try again (e.g. 'git pull <repository> <refspec>'). See
git-pull(1) for details on the refspec.


That just adjusts the "you can set some defaults" part, replacing it
with a message telling that a detached HEAD cannot have any defaults.
Without implying anything about how the user might want to work, but
giving a hint that a branch can have defaults for "git pull".

Björn

Re: Running 'git pull' from an unnamed branch

[Reece Dunn]

2009/4/6 Björn Steinbrink <B.Steinbrink@gmx.de>:
> On 2009.04.06 08:42:16 +0100, Reece Dunn wrote:
>> 2009/4/6 Junio C Hamano <gitster@pobox.com>:
>> > Reece Dunn <msclrhd@googlemail.com> writes:
>> >
>> >> diff --git a/git-pull.sh b/git-pull.sh
>> >> index 8a26763..00a72dd 100755
>> >> --- a/git-pull.sh
>> >> +++ b/git-pull.sh
>> >> @@ -97,6 +97,10 @@ error_on_no_merge_candidates () {
>> >>       echo "try again (e.g. 'git pull <repository> <refspec>')."
>> >>       echo "See git-pull(1) for details on the refspec."
>> >>       echo
>> >> +     echo "You may not be on a branch. In this case, you need to move"
>> >> +     echo "onto the branch you want to pull to (usually master):"
>> >> +     echo "    git checkout <branch>"
>> >> +     echo
>> >
>> > I do not think that is necessarily what the user wanted to hear.  Often I
>> > create trial merges on a detached HEAD when I hear a pull-request from
>> > others (I have a few work trees that share the repository with my primary
>> > working area, made with contrib/workdir/git-new-workdir script, and their
>> > HEAD are typically detached at the tip of the master), and in such a use
>> > case, the first line of the instruction in the context in your patch is
>> > the right thing to give.  I do not want to have the resulting trial merge
>> > anywhere on my real branches, and do not want to be told to switch to any
>> > of them.
>> >
>> > We really should teach people, especially the new ones early on, that "git
>> > push" and "git pull" are meant to be told where-to/from and what, and how
>> > to drive these commands with explicit arguments, before letting them rely
>> > on the default configuration blindly without understanding the underlying
>> > concepts.
>>
>> Ok, so how about something like:
>>
>> "You may not be on a branch. Because of this, you need to specify
>
> This should not say "may", either you are or you are not on a detached
> HEAD, and git can tell that, so it should not let the user have to
> guess.
>
>> where you are pulling from and to. See git-pull(1) for how to do this.
>> Alternatively, you can move to a named branch using:
>>     git checkout <branch>"
>
> Checking out a named branch won't solve the "problem" on its own.
> Consider this:
>
> git checkout origin/foo
>   *do stuff*
>
> git pull
>   *Oh! I need a named branch*
>
> git checkout -b foo
> git pull
>   *Still fails*
>
> Maybe:
> You asked me to pull without telling me which branch you want to merge
> with and as you have no branch checked out, I cannot look for any
> defaults to use. Please name which branch you want to merge on the
> command line and try again (e.g. 'git pull <repository> <refspec>'). See
> git-pull(1) for details on the refspec.

Sounds reasonable. I'll update the patch and resubmit later on today.

> That just adjusts the "you can set some defaults" part, replacing it
> with a message telling that a detached HEAD cannot have any defaults.
> Without implying anything about how the user might want to work, but
> giving a hint that a branch can have defaults for "git pull".
>
> Björn

- Reece

Re: Running 'git pull' from an unnamed branch

[Markus Heidelberg]

Björn Steinbrink, 06.04.2009:
> Maybe:
> You asked me to pull without telling me which branch you want to merge
> with and as you have no branch checked out, I cannot look for any
> defaults to use.

Hmm, let's prove this.

> Please name which branch you want to merge on the
> command line and try again

Set the config options:

    $ git config branch..remote origin
    $ git config branch..merge refs/heads/master

Verify them:

    $ git config branch..remote
    origin
    $ git config branch..merge
    refs/heads/master

Fine, the unnamed branch is set up properly for git-pull.
It _has_ to work.

    $ git checkout origin/master~1
    Note: moving to "origin/master" which isn't a local branch
    If you want to create a new branch from this checkout, you may do so
    (now or later) by using -b with the checkout command again. Example:
      git checkout -b <new_branch_name>
    HEAD is now at fbdc056... Merge branch 'jc/name-branch'

Never mind. I can ignore this message, I don't need a real branch.
git-pull will work, since I set up defaults for the unnamed branch
properly.

    $ git pull
    You asked me to pull without telling me which branch you
    want to merge with, and 'branch..merge' in
    your configuration file does not tell me either.  Please
    name which branch you want to merge on the command line and
    try again (e.g. 'git pull <repository> <refspec>').
    See git-pull(1) for details on the refspec.
    
    If you often merge with the same branch, you may want to
    configure the following variables in your configuration
    file:
    
        branch..remote = <nickname>
        branch..merge = <remote-ref>
        remote.<nickname>.url = <url>
        remote.<nickname>.fetch = <refspec>
    
    See git-config(1) for details.

Hey, above I've made sure, that branch..remote and branch..merge were
set up properly.

Damn :)