J. Bruce Fields wrote:
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.
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@xxxxxx
OP5 AB www.op5.se
Tel: +46 8-230225 Fax: +46 8-230231
-
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
