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)