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

[Lionel Elie Mamane]

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 at 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