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

["J. Bruce Fields" <bfields@fieldses.org>]

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.