openerp-community team mailing list archive

[Raphael Valyi <rvalyi@xxxxxxxxx>]

Stefan,

I know that last Friday the two topics were running in parallel:
1) the replay of OCB
2) and systematic rebase at OCB update
In fact we started investigating more deeply the concrete consequences of a
systematic rebase of OCB in French with Alexandre en Sandy.

So in case you missed it, by rebasing OCB systematically at every update
from upstream odoo:

pros:
  clean history with explicit patches that can easily be shared between OCB
7.0, 8.0 or official branches. That's kind of giving a chance for OCB not
being a fork ;-p


cons:

despite OCB will be the final branch for may be 80% of the use case, in may
be 20% of the use case, people will still need to add extra patches on it,
mostly if a patch has not been accepted in upstream OCB or if it's an
assumed quick and dirty patch with no universality pretension as it does
happen sometimes.

In that case, when updating from upstream OCB, people might get a "detached
branch" with their old sha1 that they had deployed previously. Then they
may need to tag that sha1 to avoid it to be garbage collected
automatically... In the case they want to replicate an install with the
former sha1 they used in production (say for hunting a regression), then
they may need to push that detached sha1 somewhere because it would have no
meaning on a fresh checkout of OCB...
I mean that's really a lot of plumbing to assume...

I will gladly listen to git experts, but my preference today is to go merge
instead of rebase, despite the mess. If we go for rebase, well then that
plumping should be assumed, specially in tools like Anybox recipe against
many of us are now converging.


Regards.

-- 
Raphaël Valyi
Founder and consultant
http://twitter.com/rvalyi <http://twitter.com/#!/rvalyi>
+55 21 3942-2434
www.akretion.com




On Thu, Jun 12, 2014 at 10:38 AM, Stefan <stefan@xxxxxxxx> wrote:

> Hi Raphael,
>
> thanks for taking a look!
>
>
> On 12-06-14 15:02, Raphael Valyi wrote:
>
>>
>>
>> I have no doubt that it's better to manage the final patches of a branch
>> with Github rebase interactive. Now I'm not 100% convinced yet it's the
>> best for OCB given OCB may still receive additional local patches for
>> production (were no agreement exists yet or because it's a qucik and dirty
>> production hotfix without hope to merge it upstream).
>> Because one should remember that derivating from a branch that is rebased
>> constantly is possible but not easy.
>>
>>
> You could be right about that. I'll do some tests myself, and maybe some
> of the other more git-knowledgeable people can chip in.
>
> Cheers,
> Stefan.
>
>
> --
> Therp - Maatwerk in open ontwikkeling
>
> Stefan Rijnhart - Ontwerp en implementatie
>
> mail: stefan@xxxxxxxx
> tel: +31 (0) 614478606
> web: http://therp.nl
>
>