Re: best git practices, was Re: Git User's Survey 2007 unfinished summary continued

> 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.

> 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.