Han-Wen Nienhuys [off-list ref] writes:
FWIW, I regularly mess up with the differences between fetching,
pulling and merging. In particular, having to do a two step process
to get remote changes in,
git pull url-to-server master:master
..error message about not being a fast-forward..
git pull --update-head-ok url-to-server master:master
..still an error message about update not being a fast-forward..
(sigh)
Sigh indeed.
Why don't you do the simple and obvious
git pull url master
or "git pull url" if you already know the master is the branch
you are interested in.
The more advanced form of using tracking branches are there and
documentation talks about them for completeness but that does
not mean you have to use it.
Junio C Hamano escreveu:
quoted
FWIW, I regularly mess up with the differences between fetching,
pulling and merging. In particular, having to do a two step process
to get remote changes in,
git pull url-to-server master:master
..error message about not being a fast-forward..
git pull --update-head-ok url-to-server master:master
..still an error message about update not being a fast-forward..
(sigh)
Sigh indeed.
Why don't you do the simple and obvious
git pull url master
It is not all evident from the git-pull man-page that this is the
obvious and most common usage.
or "git pull url" if you already know the master is the branch
you are interested in.
Because I usually replace verbose commands with shortcuts only when I
understand exactly what the shortcut is.
To me it's very unlogical that
master:current-branch
doesn't work, but
master:
does work, and does what I'd expect
master:current-branch
to do. Interestingly, doing
pull ..url.. master:HEAD
also doesn't merge into the current branch, but rather creates a bogus
refs/heads/HEAD
I use the remote:local syntax, because I started using GIT in scripted
compiles from copied branches of remote repositories. There the explicit
remote:local statements are necessary because there is no default branch.
--