On 28 November 2017 at 22:52, Lubomir I. Ivanov wrote:
> On 28 November 2017 at 22:45, Dirk Hohndel wrote:
>> On Tue, Nov 28, 2017 at 10:32:24PM +0200, Lubomir I. Ivanov wrote:
>>> >
>>> > Thanks for figuring this out, Lubomir!
>>> >
>>> > so, how are we
On 28 November 2017 at 22:45, Dirk Hohndel wrote:
> On Tue, Nov 28, 2017 at 10:32:24PM +0200, Lubomir I. Ivanov wrote:
>> >
>> > Thanks for figuring this out, Lubomir!
>> >
>> > so, how are we supposed to write those now? A simple hack would of course
>> > be
>> > to actually
On Tue, Nov 28, 2017 at 10:32:24PM +0200, Lubomir I. Ivanov wrote:
> >
> > Thanks for figuring this out, Lubomir!
> >
> > so, how are we supposed to write those now? A simple hack would of course be
> > to actually have a folder release_notes where everybody add _files_ for
> > things to report
On 28 November 2017 at 22:24, Robert Helling wrote:
> Hi,
>
>
> On 28. Nov 2017, at 03:48, Dirk Hohndel wrote:
>
> We should try this - but in a simpler way. Have an actual Changelog style
> file instead of the current format.
> So change ReleaseNotes.txt to
Hi,
> On 28. Nov 2017, at 03:48, Dirk Hohndel wrote:
>
> We should try this - but in a simpler way. Have an actual Changelog style
> file instead of the current format.
> So change ReleaseNotes.txt to simply say "As of v4.7.5 we are tracking the
> changes in the Changelog
> On Nov 27, 2017, at 5:13 PM, Lubomir I. Ivanov wrote:
>
> .gitattributes
> /ReleaseNotes.txt -text merge=union
>
> so it seems that it doesn't like the layout of your file:
>
On 28 November 2017 at 02:53, Lubomir I. Ivanov wrote:
> On 28 November 2017 at 02:42, Lubomir I. Ivanov wrote:
>> On 28 November 2017 at 02:07, Thiago Macieira wrote:
>>> On Monday, 27 November 2017 15:18:19 PST Lubomir I. Ivanov
On 28 November 2017 at 02:42, Lubomir I. Ivanov wrote:
> On 28 November 2017 at 02:07, Thiago Macieira wrote:
>> On Monday, 27 November 2017 15:18:19 PST Lubomir I. Ivanov wrote:
>>> > Isn’t this what we are looking for:
>>> >
>>> >
On 28 November 2017 at 02:07, Thiago Macieira wrote:
> On Monday, 27 November 2017 15:18:19 PST Lubomir I. Ivanov wrote:
>> > Isn’t this what we are looking for:
>> >
>> > http://krlmlr.github.io/using-gitattributes-to-avoid-merge-conflicts/
>>
>> i think, yes. that's exactly
On Monday, 27 November 2017 15:18:19 PST Lubomir I. Ivanov wrote:
> > Isn’t this what we are looking for:
> >
> > http://krlmlr.github.io/using-gitattributes-to-avoid-merge-conflicts/
>
> i think, yes. that's exactly what we are looking for.
> i wonder if it would work with the current
On Monday, 27 November 2017 14:19:50 PST Lubomir I. Ivanov wrote:
> maybe we can think of a mechanic to avoid the release note conflicts,
> as these are more common now that everyone edits the file next to a
> pull request.
The way we do in Qt is to add it to the commit message. Later, in the
On 28 November 2017 at 00:45, Dirk Hohndel wrote:
>
> On Nov 27, 2017, at 2:19 PM, Lubomir I. Ivanov wrote:
>
> hello,
>
> maybe we can think of a mechanic to avoid the release note conflicts,
> as these are more common now that everyone edits the file next
> On Nov 27, 2017, at 2:19 PM, Lubomir I. Ivanov wrote:
>
> hello,
>
> maybe we can think of a mechanic to avoid the release note conflicts,
> as these are more common now that everyone edits the file next to a
> pull request.
>
> Currently, if they are 2 pending
hello,
maybe we can think of a mechanic to avoid the release note conflicts,
as these are more common now that everyone edits the file next to a
pull request.
Currently, if they are 2 pending pull-requests at Github and one of
them gets merged there is a good change that this will create a merge
14 matches
Mail list logo