Re: New ponding: Urs Liska Berne lectures (issue 94960043)

[Urs Liska]

Am 05.05.2014 10:49, schrieb James:
> On 05/05/14 05:42, Urs Liska wrote:
> > Am 05.05.2014 03:50, schrieb Graham Percival:
> > > On Fri, May 02, 2014 at 06:02:48PM +0000, address@hidden
> > > wrote:
> > > > Updated patch, now applied to master.
> > >
> > > I hope you mean "now applied to staging".  You should never push
> > > anything directly to master.
> >
> > Well, Patchy the autobot complained that the initial patch didn't
> > apply to master ...
> >
> > But don't worry, I'm fully aware of the set-up and will of course move
> > the commit to the current HEAD of _staging_ when time comes to push.
> >
> > Urs
>
> Patchy compiles *against* master as that is always the benchmark (so to
> speak).
>
> If it doesn't compile against master then there is no point checking it
> in to staging.
>
> Then when patchy eventually comes to merge the two (staging and master)
> and it fails then we still have a working master and only staging is
> broken.
>
> James

What I do is branching off from master and work on the patch.
When I'm ready to upload for review I pull any new commits from origin, 
rebase my branch to master and do git cl upload origin/master - which is 
what the CG suggests.

When the review is finished I pull again and (now) apply my patch on 
staging and push there.
Previously I rebased my branch on master again and sent the patch to the 
list because I thought that staging might have changed already when 
someone handles my request.

So I think everything is clear.

But if you would prefer that one _always_ works against staging the CG 
section 3.3.4 should be changed.

Urs