Re: best git practices, was Re: Git User's Survey 2007 unfinished summary continued
- From
- J. Bruce Fields <bfields@fieldses.org>
- Date
- Oct 24, 2007, 19:48 UTC
- Message-ID
- <20071024194849.GH29830@fieldses.org>
- In-Reply-To
- <471F9FD1.6080002@op5.se>
On Wed, Oct 24, 2007 at 09:41:05PM +0200, Andreas Ericsson wrote:
Show 59 quoted lines
> 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.