[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

Re: [Freeipa-devel] [PATCH] 0330 - Add comment about last change to VERSION



On 12/09/2013 02:35 PM, Simo Sorce wrote:
> On Mon, 2013-12-09 at 12:39 +0100, Martin Kosek wrote:
>> On 12/09/2013 12:08 PM, Tomas Babej wrote:
>>> On 12/05/2013 01:37 PM, Petr Viktorin wrote:
>>>> Consider this scenario:
>>>>
>>>> - Nathaniel submits RADIUS patches that update the API version (from 2.69 to
>>>> 2.70)
>>>> - I have ACI patches that also bump the version (from 2.69 to 2.70)
>>>> - Nathaniel's patches gets accepted
>>>> - I rebase my ACI patches onto master. Git thinks that the 2.69->2.70 change
>>>> is already done, so it leaves VERSION unchanged.
>>>>
>>>> I can solve this locally by telling Git to not merge VERSION automatically,
>>>> but I think it would be helpful to add a unique comment to each change so
>>>> that everyone gets a conflict cases like this.
>>>> Do you agree?
>>>>
>>>>
>>>>
>>>> _______________________________________________
>>>> Freeipa-devel mailing list
>>>> Freeipa-devel redhat com
>>>> https://www.redhat.com/mailman/listinfo/freeipa-devel
>>>
>>> Makes sense to me.
>>>
>>> I'd just add a comment so that the purpose of the last change comment is also
>>> obvious for the new developer perusing the VERSION file.
>>>
>>> Maybe something along the lines of:
>>>
>>>  ########################################################
>>>  IPA_API_VERSION_MAJOR=2
>>>  IPA_API_VERSION_MINOR=70
>>> +# Update the last change entry to enforce conflict on merging two independent
>>> branches into master.
>>> +# Last change: npmccallum - RADIUS support
>>
>> I spoke with Petr offline, to me it would make bigger sense if we just forbid
>> automatic merging of this line on the git server side (if possible) instead of
>> adding other arbitrary work to our development process.
>>
>> IIRC, Petr3 said it should be possible to do.
> 
> Except it may not fix the issue, if someone does a rebase on his machine
> and resubmit a patch to the list w/o noticing the change was effectively
> dropped.
> 
> Simo.

I thought that the point of the anti-merge protection is to prevent git merging
tools to prevent automatic rebase of this particular line and force manual
merging, i.e. force increasing the number.

Martin


[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]