ReleaseNotes.txt and merge conflicts

Lubomir I. Ivanov neolit123 at gmail.com
Tue Nov 28 12:32:24 PST 2017


On 28 November 2017 at 22:24, Robert Helling <helling at atdotde.de> wrote:
> Hi,
>
>
> On 28. Nov 2017, at 03:48, Dirk Hohndel <dirk at hohndel.org> 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 file"
> I can come up with a way to add the version markers in the Changelog file
> automatically at release time.
> And if I feel ambitious, I can even copy things over
>
> 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 and then for a release we cat all those files…
>

yesterday, we figured out that if we have a "release notes" file where
multiple branches / commits add notes on top of it (i.e. line 1) there
won't be any conflicts between the branches if we add this:

<path>/ReleaseNotes.txt -text merge=union
in a file /.gitattributes

until we restructure our ReleaseNotes, we have to resolve conflicts
locally and force push to the remote branch from which the PR is
happening.
the github "resolve conflicts" feature with the online editor merges
master into the user branch without fast-forward (--no-ff) and i don't
think we want that.

lubomir
--


More information about the subsurface mailing list