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.