On 12/09/2013 02:50 PM, Martin Kosek wrote:
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
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 (fr
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
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 pa
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.
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 alr
