On 8. 11. 2012, at 11:52, Denis Golovin <dgolovin(a)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.
-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
>
https://lists.jboss.org/mailman/listinfo/jbosstools-dev