Re: Pushing patches to staging

[David Kastrup]

Carl Sorensen <address@hidden> writes:

> On 11/12/11 3:08 PM, "Graham Percival" <address@hidden> wrote:
>
>>
>>
>>The only problem is to develop a series of simple commands to do
>>this task.
>
> Here's my set of simple commands:
>
> git checkout master
> git pull origin master

If you did your own development on master, you now have a _merge_ of
your work with that on origin.  Not going to make people happy.

> git apply my_patch_file_name_goes_here

That means that the work consists of _one_ set of changes without
structure.  It also means that you _complete_ bypass commit management
of git.  If somebody else tries getting the same change set into git,
there is no way for git to know that it is not already part of the
history.

> git checkout staging

Since "git apply" does not create a commit of its own, this will only
work when staging has not touched independent files.

> git pull origin staging

The same applies here.

> git cherry-pick master

Why did you tamper with master in the first place instead of working on
staging?  Your master is now out of synch with upstream?

> git push origin staging
>
> These commands will work, unless some patch already applied to staging
> has messed with the files in such a way that the cherry-pick fails.
> When the cherry-pick fails, I don't know of a way to do it without
> thinking.  At that point, thought will be necessary.  Most often I
> will finish the cherry-pick by doing
>
> git mergetool
>
> And solving the merge conflicts that show up, then committing the results
> using the command that git gave me in the error message that said the
> cherry-pick wouldn't apply.

What point is the meddling with master in this recipe?  Why don't you
checkout staging, work with it, and push the results?  Why do you run
the risk that git will, once you write git push, clobber _both_ master
and staging with independent commits (a cherry-pick is usually a
different commit from its source)?

-- 
David Kastrup