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. > The problem described can only happen with a shared repository. > In a workflow that pulls from read-only repos and pushes to a > private repo that is read-only for others, such a problem cannot > happen. Because in a non-shared repository the branches cannot > be advanced by others. But in a shared repository they can. Actually I push to my public repo from multiple working repositories (because usually I work on my laptop, but sometimes I do work from a different machine), so the above can still happen. --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
