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

From: Andreas Ericsson <ae@op5.se>
Date: Oct 24, 2007, 20:13 UTC
Message-ID: <471FA751.4000603@op5.se>
In-Reply-To: <20071024194849.GH29830@fieldses.org>

J. Bruce Fields wrote:

Show 64 quoted lines

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

A better way to avoid that error message is ofcourse to make sure one always starts development off of the latest version of the particular branch one wants to work on.

Show 5 quoted lines

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

For a corporate environment with multiple modules, the scenario where the upstream is modified and the local branches aren't is more common than anything else. The failure on push happens because developers do

git pull; # Yup, gotta do that to get the latest changes git checkout whatever; # Here's where I want to work work work work git push; # ach crivens! bloody stupid git of a tool to ALWAYS BREAK!

>  In other cases the "git push" will still emit a
> spurious error.
>

If the tool can make it happen as few times as possible, that's good enough for me. It's a lot easier to explain to my co-workers that their push failed because someone else worked on it simultaneously and pushed before they did, rather than telling them that they did the pull/checkout sequence in the wrong order.

In the one scenario, it's "oh, I see". In the other, it's "god damn piece of shit tool". Simple as that.

-- 
Andreas Ericsson                   andreas.ericsson@op5.se
OP5 AB                             www.op5.se
Tel: +46 8-230225                  Fax: +46 8-230231