Hi Neels,
On Wed, Nov 01, 2017 at 01:53:48PM +0100, Neels Hofmeyr wrote:
I noticed another failure in using 'checkout
-f' to update a specific branch --
it's a deja vu, I've had these problems before: if I have a git clone that once
did 'checkout [-f] branch', and if then origin/branch gets updates, doing
another 'checkout -f branch' only goes back to the local tracking-branch of
origin/branch. We never pull in changes from origin/branch anymore as soon as a
local branch exists. Last time solutions were using 'git reset --hard', which
confuses local branches, and finally to just wipe the clone every time.
"checkout -f -B local_foo origin/foo" is IMHO the corect approach, which
I also do in my Dockerfiles, AFAIR.
Checking out a remote branch name using a local branch name (e.g.
expanding aper_prefix to origin/aper_prefix if aper_prefix doesn't
exist) is a mis-feature in git, IMHO. It's confusing.
Even when working with git interactively, I always explicitly qualify
branch names wit their 'remote' such as 'origin'. When working with
half a dozen or more remotes in a given repository it becomes very
confusing otherwise anyway.
This time I think it's best to always prepend
'origin/', so that 'checkout -f'
goes into detached-HEAD state onto the newest fetched revision.
correct. And '-B foo' is an "and create a local branch with the naem
'foo' and overwrite any existing branch with the name 'foo' if it
exists"
--
- Harald Welte <laforge(a)gnumonks.org>
http://laforge.gnumonks.org/
============================================================================
"Privacy in residential applications is a desirable marketing option."
(ETSI EN 300 175-7 Ch. A6)