I think I will wait then.

After that, I should merge my branch with master on my new fork and then create a pull request, right?

What will happen with unfinished work on our forks after the split? There will be a way to merge it to the new fork (from the split)?

Thanks,
Leonardo.

On Tue, Feb 1, 2011 at 11:53 AM, Geoffrey De Smet <ge0ffrey.spam@gmail.com> wrote:
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@gmail.com> 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@gmail.com> 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@gmail.com> 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@gmail.com> 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@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/rules-dev


_______________________________________________
rules-dev mailing list
rules-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/rules-dev




_______________________________________________
rules-dev mailing list
rules-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/rules-dev


_______________________________________________ rules-dev mailing list rules-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/rules-dev

-- 
With kind regards,
Geoffrey De Smet