On Wed, Oct 24, 2007 at 09:41:05PM +0200, Andreas Ericsson wrote: > J. Bruce Fields wrote: >> On Wed, Oct 24, 2007 at 08:48:54PM +0200, Steffen Prohaska wrote: >>> The central shared repo is called project-shared.git and contains, >>> for example, the following branches: >>> master >>> next >>> work/topicA >>> work/topicB >>> ... >>> >>> >>> Developers clone the repo and check out the branches they are >>> interested in. For example a developer may want to track next >>> and work on topicB: >>> >>> git clone ssh://central.example.com/project-shared.git project >>> cd project >>> git checkout -b next origin/next >>> git checkout -b work/topicB origin/work/topicB >>> >>> This is sufficient. No adding of remotes is needed. Neither >>> is a private repository on a server required. After cloning, >>> developers have all they need. >>> >>> Later work/topicB has new commits and should be pushed: >>> >>> git push origin >>> >>> The default behaviour of push is fine. Only matching branches >>> are pushed. >>> >>> _But_, origin is a shared repository. Therefore branches may >>> have advanced and git push may report >>> >>> error: remote 'refs/heads/next' is not a strict subset of local ref >>> 'refs/heads/next'. maybe you are not up-to-date and need to pull first? >>> >>> So here's the problem. The developer didn't do anything wrong. >>> But git complaints with an error. Git also recommends to run >>> pull, so the developer runs "git pull". But this doesn't help, >>> because it's only updating work/topicB and "git push" will >>> complain with the very same error. >>> >>> What you need to do is >>> >>> git checkout <local-branch> >>> git pull >>> git checkout <local-branch2> >>> git pull >>> ... >>> >>> for every local branch. >> Or just >> git push origin work/topicB >> since that's all you really wanted to push anyway. > > git pull. Not git push. git pull operates on one working branch > at a time (by default), whereas git push uploads and fast-forwards > all the common branches (by default). I understand. I was just suggesting that if the goal was to avoid the error message on push, then specifying the branch to push explicitly would be a solution. > I want git pull to work like git push. That strikes me as a less complete solution, since it only helps in the case where the other branches all happen to be unmodified locally (hence can be fast-forwarded). In other cases the "git push" will still emit a spurious error. --b. - To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
