You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@camel.apache.org by Claus Ibsen <cl...@gmail.com> on 2017/10/14 12:28:39 UTC
[IMPORTANT] - When you merge github PRs
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.
--
Claus Ibsen
-----------------
http://davsclaus.com @davsclaus
Camel in Action 2: https://www.manning.com/ibsen2
Re: [IMPORTANT] - When you merge github PRs
Posted by Alex Dettinger <al...@gmail.com>.
Thanks Pascal.
On Sun, Oct 15, 2017 at 9:47 PM, Pascal Schumacher <pascalschumacher@gmx.net
> wrote:
> Am 14.10.2017 um 16:17 schrieb Alex Dettinger:
>
>> 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 ?
>>
>
> As far as I know "committed with" is displayed on github when the author
> and the commiter of the commit are different. Here BruceKuiLiu is the
> author and you are the committer. Git adds you as the commiter when you
> cherry-pick a commit, so I guess you cherry-picked the commit in the branch.
>
> Cheers,
> Pascal
>
Re: [IMPORTANT] - When you merge github PRs
Posted by Pascal Schumacher <pa...@gmx.net>.
Am 14.10.2017 um 16:17 schrieb Alex Dettinger:
> 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 ?
As far as I know "committed with" is displayed on github when the author
and the commiter of the commit are different. Here BruceKuiLiu is the
author and you are the committer. Git adds you as the commiter when you
cherry-pick a commit, so I guess you cherry-picked the commit in the branch.
Cheers,
Pascal
Re: [IMPORTANT] - When you merge github PRs
Posted by Alex Dettinger <al...@gmail.com>.
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.
>>
>>
>>
>>
>
Re: [IMPORTANT] - When you merge github PRs
Posted by Pascal Schumacher <pa...@gmx.net>.
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.
>
>
>
Re: [IMPORTANT] - When you merge github PRs
Posted by Jean-Baptiste Onofré <jb...@nanthrax.net>.
Good point. It would need extra Jenkins jobs for components, etc.
Nevermind.
Regards
JB
On Oct 14, 2017, 17:58, at 17:58, Claus Ibsen <cl...@gmail.com> wrote:
>On Sat, Oct 14, 2017 at 5:00 PM, Jean-Baptiste Onofré <jb...@nanthrax.net>
>wrote:
>> Hi
>>
>> In Karaf I configured a Jenkins build to be triggered on each PR. The
>results are in the PR comments and so you can merge only if the build
>is green on Jenkins.
>>
>> Maybe we can setup the same in camel ?
>>
>
>I dont think so as a full build is 4+ hours. And jenkins is not smart
>enough to only build a sub set of a PR such as if you only change in
>camel-aws, then only test camel-aws etc.
>
>Also we have a bit of trouble as some of the CI servers are too
>limited spec'ed with memory so they can't build the project either.
>
>
>
>> Regards
>> JB
>>
>> On Oct 14, 2017, 14:48, at 14:48, Grzegorz Grzybek
><gr...@gmail.com> wrote:
>>>Hello
>>>
>>>+1
>>>
>>>Also, when you backport (e.g., from master to 2.19.x) changes by
>>>cherry-pick, use:
>>>
>>>git cherry-pick -x
>>>
>>>which gives automatic reference to picked commit (SHA1) in the new
>>>commit
>>>message.
>>>
>>>regards
>>>Grzegorz Grzybek
>>>
>>>2017-10-14 14:28 GMT+02:00 Claus Ibsen <cl...@gmail.com>:
>>>
>>>> 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.
>>>>
>>>>
>>>>
>>>> --
>>>> Claus Ibsen
>>>> -----------------
>>>> http://davsclaus.com @davsclaus
>>>> Camel in Action 2: https://www.manning.com/ibsen2
>>>>
>
>
>
>--
>Claus Ibsen
>-----------------
>http://davsclaus.com @davsclaus
>Camel in Action 2: https://www.manning.com/ibsen2
Re: [IMPORTANT] - When you merge github PRs
Posted by Claus Ibsen <cl...@gmail.com>.
On Sat, Oct 14, 2017 at 5:00 PM, Jean-Baptiste Onofré <jb...@nanthrax.net> wrote:
> Hi
>
> In Karaf I configured a Jenkins build to be triggered on each PR. The results are in the PR comments and so you can merge only if the build is green on Jenkins.
>
> Maybe we can setup the same in camel ?
>
I dont think so as a full build is 4+ hours. And jenkins is not smart
enough to only build a sub set of a PR such as if you only change in
camel-aws, then only test camel-aws etc.
Also we have a bit of trouble as some of the CI servers are too
limited spec'ed with memory so they can't build the project either.
> Regards
> JB
>
> On Oct 14, 2017, 14:48, at 14:48, Grzegorz Grzybek <gr...@gmail.com> wrote:
>>Hello
>>
>>+1
>>
>>Also, when you backport (e.g., from master to 2.19.x) changes by
>>cherry-pick, use:
>>
>>git cherry-pick -x
>>
>>which gives automatic reference to picked commit (SHA1) in the new
>>commit
>>message.
>>
>>regards
>>Grzegorz Grzybek
>>
>>2017-10-14 14:28 GMT+02:00 Claus Ibsen <cl...@gmail.com>:
>>
>>> 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.
>>>
>>>
>>>
>>> --
>>> Claus Ibsen
>>> -----------------
>>> http://davsclaus.com @davsclaus
>>> Camel in Action 2: https://www.manning.com/ibsen2
>>>
--
Claus Ibsen
-----------------
http://davsclaus.com @davsclaus
Camel in Action 2: https://www.manning.com/ibsen2
Re: [IMPORTANT] - When you merge github PRs
Posted by Jean-Baptiste Onofré <jb...@nanthrax.net>.
Hi
In Karaf I configured a Jenkins build to be triggered on each PR. The results are in the PR comments and so you can merge only if the build is green on Jenkins.
Maybe we can setup the same in camel ?
Regards
JB
On Oct 14, 2017, 14:48, at 14:48, Grzegorz Grzybek <gr...@gmail.com> wrote:
>Hello
>
>+1
>
>Also, when you backport (e.g., from master to 2.19.x) changes by
>cherry-pick, use:
>
>git cherry-pick -x
>
>which gives automatic reference to picked commit (SHA1) in the new
>commit
>message.
>
>regards
>Grzegorz Grzybek
>
>2017-10-14 14:28 GMT+02:00 Claus Ibsen <cl...@gmail.com>:
>
>> 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.
>>
>>
>>
>> --
>> Claus Ibsen
>> -----------------
>> http://davsclaus.com @davsclaus
>> Camel in Action 2: https://www.manning.com/ibsen2
>>
Re: [IMPORTANT] - When you merge github PRs
Posted by Grzegorz Grzybek <gr...@gmail.com>.
Hello
+1
Also, when you backport (e.g., from master to 2.19.x) changes by
cherry-pick, use:
git cherry-pick -x
which gives automatic reference to picked commit (SHA1) in the new commit
message.
regards
Grzegorz Grzybek
2017-10-14 14:28 GMT+02:00 Claus Ibsen <cl...@gmail.com>:
> 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.
>
>
>
> --
> Claus Ibsen
> -----------------
> http://davsclaus.com @davsclaus
> Camel in Action 2: https://www.manning.com/ibsen2
>