Re: [smarthome-dev] Merge strategy

[Markus Rathgeb <maggu2810@xxxxxxxxx>]

There has been some errors today (https://status.github.com/messages).
I merged a PR today and Github response some time later that there has
been something wrong (I assume missing asynchronous message). As I am
informed about this problems I closed the tabs and wait some time. I
opened the PR later and see the PR has been merged. So, I assume that
it is caused by some Github hiccup.
Thanks for your report.

2016-04-05 21:15 GMT+02:00 Kai Kreuzer <kai@xxxxxxxxxxx>:
> Hm, something is weird. I just tried to do it with https://github.com/eclipse/smarthome/pull/1331 for the first time, and somehow there are now two commits in the repo (one being empty). But I guess this is due to a Github hiccup, since the first merge attempt resulted in an Github error message and left the PR unmerged (while having done the commit in the background nonetheless). Probably this feature is still a bit buggy, so please be warned :-)
>
> Kai
>
>
>> On 05 Apr 2016, at 17:28, Kai Kreuzer <kai@xxxxxxxxxxx> wrote:
>>
>>> It should be done my the committer (merging one). The author does not
>>> know the PR number if he creates his commit because the PR is created
>>> after the one or the multiple commits.
>>
>> Ok, agree.
>>
>>> The "committer" (not the Git jargon, but the Eclipse one) guidelines
>>> have to be changed, that the committer / merging person adds a PR
>>> line.
>>
>> As we do not have any formal guidelines written down for ESH here, I think this discussion between us on this list should suffice.
>>
>> So fine for me to switch to the new mode.
>>
>>> Am 05.04.2016 um 11:38 schrieb Markus Rathgeb <maggu2810@xxxxxxxxx>:
>>>
>>>> Hm, right, by not having a merge commit anymore, we are losing the automatic references to the PRs, what is not nice.
>>>
>>> Also with the merge commit it is not nice.
>>> Example:
>>> commit A has been created on 2016-03-01
>>> commit A has been merged on 2016-04-04, so there is a merge commit B
>>> with the date 2016-04-04
>>> If we look at the log of the commits the two commits are separated by
>>> a lot of other commits.
>>> I do not know an eady way to find the merge commit (B) of commit A to
>>> see which PR commit A is part of.
>>> I can use the Github search but this is another point and not really nice.
>>>
>>>> I think it is therefore important to manually add the reference in the commit message, yes.
>>>> Should this be done by the author or the committer?
>>>
>>> It should be done my the committer (merging one). The author does not
>>> know the PR number if he creates his commit because the PR is created
>>> after the one or the multiple commits.
>>>
>>>> We would need to update the contributing documentation before we switch to this new mode. It probably also makes sense to do the same process changes in openHAB, so that contributors from there are not confused about what style has to be done where.
>>>
>>> The author / PR creator does not need to change anything (IMHO), he
>>> creates his PR as before.
>>> The "committer" (not the Git jargon, but the Eclipse one) guidelines
>>> have to be changed, that the committer / merging person adds a PR
>>> line.
>>> _______________________________________________
>>> smarthome-dev mailing list
>>> smarthome-dev@xxxxxxxxxxx
>>> To change your delivery options, retrieve your password, or unsubscribe from this list, visit
>>> https://dev.eclipse.org/mailman/listinfo/smarthome-dev
>>
>> _______________________________________________
>> smarthome-dev mailing list
>> smarthome-dev@xxxxxxxxxxx
>> To change your delivery options, retrieve your password, or unsubscribe from this list, visit
>> https://dev.eclipse.org/mailman/listinfo/smarthome-dev
>
> _______________________________________________
> smarthome-dev mailing list
> smarthome-dev@xxxxxxxxxxx
> To change your delivery options, retrieve your password, or unsubscribe from this list, visit
> https://dev.eclipse.org/mailman/listinfo/smarthome-dev