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/#%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.
Cheers,
Stefan.
--
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
