[jbosstools-dev] JBoss Tools is branched for 4.0.0.Beta2

[Rob Cernich]

----- Original Message -----

> On 8. 11. 2012, at 14:40, Rob Cernich < rcernich at redhat.com > 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). 

> -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 at lists.jboss.org
> > 
> 
> > > https://lists.jboss.org/mailman/listinfo/jbosstools-dev
> > 
> 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/jbosstools-dev/attachments/20121108/d1bf0fff/attachment.html