Re: bad merge in staging

[David Kastrup]

"address@hidden" <address@hidden> writes:

> Le Dec 11, 2011 à 3:04 PM, David Kastrup a écrit :
>
>> 
>> If Mike had used git pull -r instead of a plain pull without rebase,
>> this "mess" would not have happened.
>
>
> Ok - will do from here on out.

The problem is that it is hard to prescribe a universal recipe for how
to use pull because pull can be used in many situations.

I would actually prefer if people _never_ actually did any work on their
own copy of staging.

The reason is that git has no way to distinguish work done by the user
himself from residue left around after the upstream staging had to back
out some changes.

Whether or not you use pull -r or pull or whatever else, you might have
more than just your own changes in your local copy staging when compared
to upstream.

That's why I first do git fetch, then something like
git checkout -B staging origin/staging
which _destroys_ the current version of staging and replaces it with
that from origin, then

git cherry-pick feature-commit

git rebase origin/staging feature-branch

(note that you now may have the current state of staging embedded in
your feature-branch and might need to back it out again if the
feature-branch gets thrown out of staging along with other material)

before
git push origin HEAD:staging

More often than not, the HEAD I push to staging is not on a proper
branch.

-- 
David Kastrup