Re: [rules-dev] Clean up your topic branches on the github reference repository

Leonardo, Yea, I believe Estaban's right, but there's bigger problem... I was hoping that all those topic branches were already merged into master and none had to survive, but yours does. As soon as 5.2.0.M1 is out, we'll announce a date to split-up the droolsjbpm repository into smaller repositories (drools, jbpm, guvnor, planner, eclipse, ...), so that will basically impact all forks... as they will basically have to be re-forked. I know this is very annoying if you forked the droolsjbpm repo, but the split-up needs to be done as it will make life a lot better for us (see seam 3 and hibernate 4 repos). So, for these topic branches that need to survive: I am ok to *leave those surviving topic branches on the blessed repo until after the split-up*, which should make it easier to move them into your fork then. But please delete your topic branches that have been merged into master long ago. Op 31-01-11 15:13, Esteban Aliverti schreef: I think when you create a fork you are also "copying" all the branches. So you will have all your code there. Then you should do a merge between your brach (in your fork) and the master (also in your fork). Then you could perform a pull request. I'm not sure if this is correct. Let us wait for someone with more experience in git to correct me. Best Regards, XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX Esteban Aliverti - Developer @ http://www.plugtree.com - Blog @ http://ilesteban.wordpress.com On Mon, Jan 31, 2011 at 10:58 AM, Leonardo Gomes < leonardo.f.gomes(a)gmail.com&gt; wrote: > Hi Geoffrey, > > Let me check if I understood the procedure: > > 1) You want us to fork: https://github.com/droolsjbpm/droolsjbpm > > 2) Then apply the changes that are in our forked branch (in my case, > https://github.com/leogomes/droolsjbpm/tree/lr_unlinking_20101116) > to our forked main (https://github.com/leogomes/droolsjbpm) > > 3) Remove the branch > > 4) And, when we are done we the work on our fork, create a pull request to > deliver the changes to the master. > > That's it? If so, is there an easy way to do 2, other than generating a > patch and applying it manually? > > Thanks, > Leonardo. > > > > > On Mon, Jan 24, 2011 at 3:52 PM, Leonardo Gomes < > leonardo.f.gomes(a)gmail.com&gt; wrote: > >> Hi, >> >> I'm planning to get rid of "lr_unlinking_20101116" over the weekend. >> >> Cheers, >> Leonardo. >> >> On Thu, Jan 20, 2011 at 2:45 PM, Esteban Aliverti < >> esteban.aliverti(a)gmail.com&gt; wrote: >> >>> trunk_20100722_esteban_diega branch and tag are no longer among us :( >>> I have also deleted guvnor_expressionEditor3_baunax_esteban_20100202 tag >>> >>> Best Regards, >>> >>> XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX >>> >>> Esteban Aliverti >>> - Developer @ http://www.plugtree.com >>> - Blog @ http://ilesteban.wordpress.com >>> >>> >>> >>> On Thu, Jan 20, 2011 at 10:03 AM, Geoffrey De Smet < >>> ge0ffrey.spam(a)gmail.com&gt; wrote: >>> >>>> Hi guys, >>>> >>>> In the github reference repository >>>> https://github.com/droolsjbpm/droolsjbpm >>>> we have /release branches/, such as 4.0.x, 5,0.x, 5.1.x, 5.2.0.M1.x, >>>> ... >>>> which is fine, >>>> but also topic branches which clutter our reference repository. >>>> >>>> Following the conventions of other projects, we'd like to move all >>>> topic >>>> branches out of the github reference repository, by: >>>> >>>> * 1) Removing the topic branch if it has been merged into master >>>> long ago and has become irrelevant >>>> * 2) Keep the topic branch local (if it's short-lived) until it's >>>> merged into master >>>> * 3) Forking the reference repository on github and push your topic >>>> branches there, until it's merged into master >>>> o For example, edson's fork: >>>> https://github.com/etirelli/droolsjbpm >>>> >>>> Here's a list of the topic branches that we want to get rid of. >>>> If one of them is yours, please read on. >>>> >>>> * Branch_4_0_2_SOA_4_2 >>>> * DRLv6 >>>> * DROOLS_4_0_2_SOA_4_2_GA >>>> * DroolsChance >>>> * K200 >>>> * effective_dated >>>> * guvnor-pre-guided-changes-june-09 >>>> * kstam_guvnor_modeshape >>>> * lr_unlinking_20101116 >>>> * persistence_refactor >>>> * rete_using_static_methods_aug2009trunk_20100722_esteban_diega >>>> >>>> If 1) applies and it has been merged into master long ago and has >>>> become >>>> irrelevant, then just remove it with this command: >>>> $ git push origin :<branchname> >>>> For example: >>>> $ git push origin :kstam_guvnor_modeshape >>>> >>>> If 2) or 3) applies, its a bit more difficult, but I'll make a blog in >>>> a >>>> few weeks on how to fork and do social coding. >>>> >>>> -- >>>> With kind regards, >>>> Geoffrey De Smet >>>> >>>> >>>> _______________________________________________ >>>> rules-dev mailing list >>>> rules-dev(a)lists.jboss.org >>>> https://lists.jboss.org/mailman/listinfo/rules-dev >>>> >>> >>> >>> _______________________________________________ >>> rules-dev mailing list >>> rules-dev(a)lists.jboss.org >>> https://lists.jboss.org/mailman/listinfo/rules-dev >>> >>> >> > > _______________________________________________ > rules-dev mailing list > rules-dev(a)lists.jboss.org > https://lists.jboss.org/mailman/listinfo/rules-dev > > _______________________________________________ rules-dev mailing listrules-dev@lists.jboss.orghttps://lists.jboss.org/mailman/listinfo/rules-dev -- With kind regards, Geoffrey De Smet