camel-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Alex Dettinger <>
Subject Re: [IMPORTANT] - When you merge github PRs
Date Sat, 14 Oct 2017 14:17:19 GMT

Thanks for precisions. When I previously merged a PR
<>. I've done:

     git pull 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,

On Sat, Oct 14, 2017 at 2:48 PM, Pascal Schumacher <
> 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.

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message