Branches: https://github.com/jbosstools/jbosstools-base/tree/jbosstools-4.0.0.Beta2x https://github.com/jbosstools/jbosstools-central/tree/jbosstools-4.0.0.Be... ... Jobs: http://hudson.jboss.org/hudson/view/JBossTools/view/JBossTools_4.0.juno/ Note that we are *code frozen* for Beta2, which means only urgent fixes should be done in the branch, associated w/ a JIRA. Trunk is open for BUGFIXES ONLY. Where applicable, please remember to commit changes in BOTH trunk and the new branch.

Yesterday we discussed on IRC that this can be tricky - if you have one topic branch that was originally based on master for instance and want to apply the changes to both master and Beta2x then you need to be careful because if you rebase the Beta2x-based topic branch to master, it will contain many more new commits and you only want to cherry pick the ones you really need. That is clear to me (I hope).

But I'd like to ask another related question: What is the recommended approach wrt pull requests here? The above assumes you have one topic branch and hence one pull request. So are users supposed to comment in the pull request saying they want it to be applied to both branches? Or should they rather create to separate pull requests for each branch (from 2 different topic branches)?

Sorry if I'm asking something obvious - these are new things to me :)

On 11/08/2012 01:19 AM, Max Rydahl Andersen wrote: >> Yesterday we discussed on IRC that this can be tricky - if you have one topic branch that was originally based on master for instance and want to apply the changes to both master and Beta2x then you need to be careful because if you rebase the Beta2x-based topic branch to master, it will contain many more new commits and you only want to cherry pick the ones you really need. That is clear to me (I hope). > yes, as with any other PR that is "outofsync" cherrypicking is the way to go. > >> But I'd like to ask another related question: What is the recommended approach wrt pull requests here? The above assumes you have one topic branch and hence one pull request. So are users supposed to comment in the pull request saying they want it to be applied to both branches? Or should they rather create to separate pull requests for each branch (from 2 different topic branches)? > I would say it depends on the case - no reason to make things harder to do than necessary :) > > I would say a PR clearly marked as should going to both is enough in many cases but while we are getting our feet wet here doing one for each might be worth doing. IMO it should be done in JIRA by assigning right fix versions: 4.0.0.CR1 - for master, 4.0.0.Beta2 for - jbosstools-4.0.0.Beta2x branch.

> >> Sorry if I'm asking something obvious - these are new things to me :) > same here - we'll find a way; i'm collecting notes for all "git whoops" I see happening to adjust recommendations as we learn, so keep them coming:) > > /max > _______________________________________________ > jbosstools-dev mailing list > jbosstools-dev(a)lists.jboss.org > https://lists.jboss.org/mailman/listinfo/jbosstools-dev

On 11/08/2012 02:56 AM, Martin Malina wrote: > > On 8. 11. 2012, at 11:52, Denis Golovin <dgolovin(a)exadel.com > <mailto:dgolovin@exadel.com>> wrote: > >> On 11/08/2012 01:19 AM, Max Rydahl Andersen wrote: >>>> Yesterday we discussed on IRC that this can be tricky - if you have >>>> one topic branch that was originally based on master for instance >>>> and want to apply the changes to both master and Beta2x then you >>>> need to be careful because if you rebase the Beta2x-based topic >>>> branch to master, it will contain many more new commits and you >>>> only want to cherry pick the ones you really need. That is clear to >>>> me (I hope). >>> yes, as with any other PR that is "outofsync" cherrypicking is the >>> way to go. >>> >>>> But I'd like to ask another related question: What is the >>>> recommended approach wrt pull requests here? The above assumes you >>>> have one topic branch and hence one pull request. So are users >>>> supposed to comment in the pull request saying they want it to be >>>> applied to both branches? Or should they rather create to separate >>>> pull requests for each branch (from 2 different topic branches)? >>> I would say it depends on the case - no reason to make things harder >>> to do than necessary :) >>> >>> I would say a PR clearly marked as should going to both is enough in >>> many cases but while we are getting our feet wet here doing one for >>> each might be worth doing. >> >> IMO it should be done in JIRA by assigning right fix versions: >> 4.0.0.CR1 - for master, 4.0.0.Beta2 for - jbosstools-4.0.0.Beta2x branch. > > Yes, JIRA should always have the right fix versions set. But that > doesn't solve this problem. Or did you mean to say that the repo > maintainer should look at the JIRA to see which branches he should > apply the changes to? I don't think it's safe � Max' suggestions seem > better - either create two PRs or create one and state the destination > branches in the PR. It's safe because repo maintainer should go to jira and use workflow to mark jira as resolved. But it is fine do it through declaring branches to apply in pull request description. Denis > > -Martin > >>> >>>> Sorry if I'm asking something obvious - these are new things to me :) >>> same here - we'll find a way; i'm collecting notes for all "git >>> whoops" I see happening to adjust recommendations as we learn, so >>> keep them coming:) >>> >>> /max >>> _______________________________________________ >>> jbosstools-dev mailing list >>> jbosstools-dev(a)lists.jboss.org <mailto:jbosstools-dev@lists.jboss.org> >>> https://lists.jboss.org/mailman/listinfo/jbosstools-dev >> > > > > _______________________________________________ jbosstools-dev mailing list jbosstools-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/jbosstools-dev

----- Original Message ----- >> Yesterday we discussed on IRC that this can be tricky - if you have >> one topic branch that was originally based on master for instance >> and want to apply the changes to both master and Beta2x then you >> need to be careful because if you rebase the Beta2x-based topic >> branch to master, it will contain many more new commits and you >> only want to cherry pick the ones you really need. That is clear >> to me (I hope). > > yes, as with any other PR that is "outofsync" cherrypicking is the > way to go. > >> But I'd like to ask another related question: What is the >> recommended approach wrt pull requests here? The above assumes you >> have one topic branch and hence one pull request. So are users >> supposed to comment in the pull request saying they want it to be >> applied to both branches? Or should they rather create to separate >> pull requests for each branch (from 2 different topic branches)? > > I would say it depends on the case - no reason to make things harder > to do than necessary :) > > I would say a PR clearly marked as should going to both is enough in > many cases but while we are getting our feet wet here doing one for > each might be worth doing. I think this really depends on how consistent the history is between the two branches. If the branches have diverged, you may end up pulling in extra commits on one of the branches. It's probably best to issue separate requests for each branch. One thing that might help as your figuring things out would be to limit pull requests to a single commit (i.e. all changes for a particular JIRA should be squashed into a single commit). This will allow you to see if you're pulling in multiple commits (which you won't know if there are multiple commits in the pull). Just an idea. (Actually, this is how we run things on SwitchYard.)

> >> Sorry if I'm asking something obvious - these are new things to me >> :) > > same here - we'll find a way; i'm collecting notes for all "git > whoops" I see happening to adjust recommendations as we learn, so > keep them coming:) > > /max > _______________________________________________ > jbosstools-dev mailing list > jbosstools-dev(a)lists.jboss.org > https://lists.jboss.org/mailman/listinfo/jbosstools-dev >

On 8. 11. 2012, at 14:40, Rob Cernich <rcernich(a)redhat.com&gt; wrote: ----- Original Message ----- Yesterday we discussed on IRC that this can be tricky - if you have one topic branch that was originally based on master for instance and want to apply the changes to both master and Beta2x then you need to be careful because if you rebase the Beta2x-based topic branch to master, it will contain many more new commits and you only want to cherry pick the ones you really need. That is clear to me (I hope). yes, as with any other PR that is "outofsync" cherrypicking is the way to go. But I'd like to ask another related question: What is the recommended approach wrt pull requests here? The above assumes you have one topic branch and hence one pull request. So are users supposed to comment in the pull request saying they want it to be applied to both branches? Or should they rather create to separate pull requests for each branch (from 2 different topic branches)? I would say it depends on the case - no reason to make things harder to do than necessary :) I would say a PR clearly marked as should going to both is enough in many cases but while we are getting our feet wet here doing one for each might be worth doing. I think this really depends on how consistent the history is between the two branches. If the branches have diverged, you may end up pulling in extra commits on one of the branches. It's probably best to issue separate requests for each branch. One thing that might help as your figuring things out would be to limit pull requests to a single commit (i.e. all changes for a particular JIRA should be squashed into a single commit). This will allow you to see if you're pulling in multiple commits (which you won't know if there are multiple commits in the pull). Just an idea. (Actually, this is how we run things on SwitchYard.) Yes, I agree this would reduce the risk of adding more commits to the destination branch than intended. But on the other hand a maintainer will usually be pretty clear on what to apply - at least the original pull request should show the correct commits that you want to be added. My experience has been that Github will show you all commits that were added from the reference point on your branch. When you issue a pull request, it is against a branch, not specific commits (i.e. pull from this branch not pull these commits).

On 8. 11. 2012, at 14:55, Rob Cernich <rcernich(a)redhat.com&gt; wrote: > > > > On 8. 11. 2012, at 14:40, Rob Cernich <rcernich(a)redhat.com&gt; wrote: > > > > ----- Original Message ----- > Yesterday we discussed on IRC that this can be tricky - if you have > one topic branch that was originally based on master for instance > and want to apply the changes to both master and Beta2x then you > need to be careful because if you rebase the Beta2x-based topic > branch to master, it will contain many more new commits and you > only want to cherry pick the ones you really need. That is clear > to me (I hope). > > yes, as with any other PR that is "outofsync" cherrypicking is the > way to go. > > But I'd like to ask another related question: What is the > recommended approach wrt pull requests here? The above assumes you > have one topic branch and hence one pull request. So are users > supposed to comment in the pull request saying they want it to be > applied to both branches? Or should they rather create to separate > pull requests for each branch (from 2 different topic branches)? > > I would say it depends on the case - no reason to make things harder > to do than necessary :) > > I would say a PR clearly marked as should going to both is enough in > many cases but while we are getting our feet wet here doing one for > each might be worth doing. > > I think this really depends on how consistent the history is between the two branches. If the branches have diverged, you may end up pulling in extra commits on one of the branches. It's probably best to issue separate requests for each branch. > > One thing that might help as your figuring things out would be to limit pull requests to a single commit (i.e. all changes for a particular JIRA should be squashed into a single commit). This will allow you to see if you're pulling in multiple commits (which you won't know if there are multiple commits in the pull). Just an idea. (Actually, this is how we run things on SwitchYard.) > > Yes, I agree this would reduce the risk of adding more commits to the destination branch than intended. But on the other hand a maintainer will usually be pretty clear on what to apply - at least the original pull request should show the correct commits that you want to be added. > > My experience has been that Github will show you all commits that were added from the reference point on your branch. When you issue a pull request, it is against a branch, not specific commits (i.e. pull from this branch not pull these commits). Yes, but you will usually submit your pull request for the correct branch, not the "opposite". Let me explain: If you originally base your topic branch on Beta2x and then submit this topic branch as a pull request to be applied onto master, then github may show you more commits. But if you do any of these two, you will see the correct commits: a) Base your topic branch on Beta2x and submit pull request against Beta2x b) Base your topic branch on master and submit pull request against master So my premise was that people would normally do a) or b) (and then ask to have the changes pushed to both master and Beta2x). If you do a) or b) you should always see the correct commits in the PR on github. -Martin