On Sun, Jan 26, 2014 at 11:14 PM, Daniel James
Assuming that you haven't made any local commits, you can delete your local branch (git branch -D develop) or check it out and reset to the remote branch (git reset --hard origin/develop).
Thanks, Daniel, but I eventually re-downloaded the whole Boost repository, which seems to have fixed it. It took another couple of hours though. One question. Wouldn't 'git branch -D develop' modify my history so that it becomes out of sync with the upstream? Boost.Predef is not my library, I wouldn't want any pending changes to be in my local copy.
And I have similar problems with Boost.Build. When I do 'git submodule foreach git checkout develop' it checks out something outdated, with v2 directory at the top level, saying that it has diverged from origin/develop. Doing 'git pull', as it suggests, only brings a bunch of conflicts and merges, and a half-merged tree in tools/build.
'develop' is your local branch, which contains an older version. You can fix it as I wrote above. But it's best not to bother checking out branches for modules you aren't working on, just let the super project manage them.
The problem with 'git submodule update' is that it leaves all submodules in detached state and I can't commit any changes. Also I want to be sure that I'm modifying the latest version from git and not some intermediate version referenced by the supermodule. So I need an equivalent for 'svn update' and 'git submodule foreach git pull' is the closest replacement that I know of.
PS: I'm really running out of polite words now towards git. This pile of... bytes have given me nothing but trouble so far. I'm spending 1.5 hours now trying just to update the damn local copy, and every update command runs for ages, because apparently it authenticates for every submodule every time. Who in good will would use this... tool? <sigh> I was probably born on another planet.
Is that using 'git submodule foreach ...'?
Yes.
The command for each module is run in a new process so it can't reuse existing connections. I also imagine it's extra slow on windows as processes are quite expensive.
That's what I'm thinking as well. SVN was really faster with updates. And simpler.
'git pull' can be a bit smarter about fetching submodules, and I think 'git submodule update --init' works locally.
'git pull' (in superproject) doesn't update submodules. I'm not even sure it fetches their history, but I may be wrong. 'git submodule update --init' does fetch submodules when initializing. Not sure if that's the case when the submodule is initialized. But as I said, it leaves the submodules detached, which is not what I want.