camel-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Alex Dettinger <aldettin...@gmail.com>
Subject Re: [IMPORTANT] - When you merge github PRs
Date Sat, 14 Oct 2017 14:17:19 GMT
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 <pascalschumacher@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.
>>
>>
>>
>>
>

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