Yes, it would be great if we can do a final rebase of the branch before merging. Perhaps the squashing part already does that?
Thanks, Jun On Tue, May 5, 2015 at 5:53 AM, Ismael Juma <ism...@juma.me.uk> wrote: > Hi Jun, > > On Sat, May 2, 2015 at 2:50 PM, Jun Rao <j...@confluent.io> wrote: > > > We will also need to figure out if we need CONTRIBUTING.md like the > > following to take care of the Apache licensing stuff. > > > > https://github.com/apache/spark/blob/master/CONTRIBUTING.md > > > Yes indeed. That is in step 3 of the "missing pieces" in the original > email. > > As for merging changes, I think squashing the commits will be ideal during > > merge. > > > The script does squash commits during merge indeed. It also includes > retains a bunch of useful information in the commit message. I think one > loses some of the benefits of git when using a one squashed commit per PR > approach, but that is a separate issue and I am not suggesting a change in > this regard at this point. > > > > Also, it would be great if we can always put the latest changes on > > top during the merge. > > > > Just to make sure I understand correctly, do you mean updating the working > copy with the latest from trunk before merging? Or did I misunderstand? > > Best, > Ismael >
