← Back to team overview

openerp-community team mailing list archive

Re: Work in progress: OCB 7.0 on github


If OCB is not supposed to be a fork, then act like you are not the "upstream", just a branch like the others. Make sure it merges cleanly into official, and make the history clean you can. If rebase does that then I'd say go ahead.

From my point of view it's OK and cleaner to rebase OCB, because I for one won't mirror OCB on the production server. I'll simply fork the official branches and then merge OCB just like my other feature/bugfix branches, and re-merge from time to time. The big bonus of this approach is that you get a very clear upgrade log of the production server which is always handy to track regressions.

Lionel Sausin.

Le 12/06/2014 16:26, Raphael Valyi a écrit :

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:

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


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.


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

On Thu, Jun 12, 2014 at 10:38 AM, Stefan <stefan@xxxxxxxx <mailto: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.


-- Therp - Maatwerk in open ontwikkeling

    Stefan Rijnhart - Ontwerp en implementatie

    mail: stefan@xxxxxxxx <mailto:stefan@xxxxxxxx>
    tel: +31 (0) 614478606 <tel:%2B31%20%280%29%20614478606>
    web: http://therp.nl

Mailing list: https://launchpad.net/~openerp-community
Post to     : openerp-community@xxxxxxxxxxxxxxxxxxx
Unsubscribe : https://launchpad.net/~openerp-community
More help   : https://help.launchpad.net/ListHelp