Re: cherry-pick across renames [was: minutes of ESC call ...]

On Tue, Apr 16, 2013 at 03:46:34PM +0200, Miklos Vajna wrote:

> On Tue, Apr 16, 2013 at 08:08:20AM -0500, Norbert Thiebaud <nthiebaud@gmail.com> wrote:

> > humm... with moving of 1000's of headers... I wonder what the limit
> > will then be needed ?

> > also, that must impact gerrit too. iow I would need to increase that
> > parameter on the gerrit side so that cherry-picking works ?

> > or do we want to consider that for these few transient patch that
> > will need cherry picking accross the move, people should manually
> > rebase theses patch are re-push them to gerrit ?

> I thought our current workflow is:

> - devA cherry-picks a commit from master to -4-0
> - devA pushes to refs/for/4-0
> - devB fetches from gerrit, tests, review, then pushes the button if it
>   looks OK (or pushes to refs/heads/4-0)

> In this workflow no adjustment on the gerrit side is needed, I
> guess.

I think Norbert meant:

 - devA prepares patch *before* the headers move
 - devA pushes to refs/for/master
 - devB fetches from gerrit, tests, review, then pushes the button
 - gerrit does a rebase (automatically)

OR

 - devA prepares patch *before* the headers move
 - devA pushes to refs/for/master
 - devB pushes the "rebase" button in gerrit

IMHO, ideally we would:

 - increase the setting massively in gerrit
 - move the headers
 - wait for all the patches in gerrit made before the move to be
   treated
 - wait for a reasonable "nobody will push patches from older master
   anymore" time
 - put the setting in gerrit lower (back to default?)

-- 
Lionel