Hi, Thanks for precisions. When I previously merged a PR <https://github.com/apache/camel/pull/2038>. I've done:
git pull https://github.com/BruceKuiLiu/camel boxedParsing So next time, I'll also run git pull --rebase afterward. Apart from that, I've noticed that the merge on master ended up with a commit indication that: "BruceKuiLiu committed 22 hours ago". Whereas, the same commit cherry-picked from master to camel-2.20.x shows: "BruceKuiLiu committed *with aldettinger* 22 hours ago". So, will I have the "committed with" indication on master too next time thanks to git pull --rebase ? Or is there anything else I'm missing ? Many thanks, Alex On Sat, Oct 14, 2017 at 2:48 PM, Pascal Schumacher <pascalschumac...@gmx.net > wrote: > Thanks for the information. > > By the way, what is the camel way to merge pull requests (cherry-picking > the commit(s)?, do you squash commits e.g. changes after a review?). How do > you move changes from master to bugfix branches (cherry-picking?)? > > Thanks, > Pascal > > > Am 14.10.2017 um 14:28 schrieb Claus Ibsen: > >> Hi >> >> When you merge github PRs then its important to merge and rebuild on >> top afterwards so we have a straight git tree. >> >> So after you have done the merge, then you SHOULD run >> >> git pull --rebase >> >> Then it replay the merge on top of latest master. And if there is any >> conflicts you need to fix them, so we can merge any PR cleanly on >> latest master. >> >> Otherwise we end up with a more complex git tree that makes it harder >> to maintain and also backport bug fixes to older branches. >> >> Also refrain from backporting trivil javadoc changes and others to >> older branches. The older branches are intended to be "quiet" and for >> bug fixes and minor needed improvements only. The less changes we have >> one these the better for the end users as they are are for patch >> releases for production users. >> >> >> >> >