This is merely a historical archive of years 2008-2021, before the migration to mailman3.
A maintained and still updated list archive can be found at https://lists.osmocom.org/hyperkitty/list/OpenBSC@lists.osmocom.org/.
Harald Welte laforge at gnumonks.orgHi 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 at gnumonks.org> http://laforge.gnumonks.org/
============================================================================
"Privacy in residential applications is a desirable marketing option."
(ETSI EN 300 175-7 Ch. A6)