Merging NEWS file from stable to default

Merging changes in the NEWS file from stable to default is somewhat awkward now. Changes to that file on the stable branch are automatically merged to etc/NEWS.7 and NEWS.
Ideally it would only merge to etc/NEWS.7. IIRC, it did work that way while Octave 6 was on stable.
Is it possible to somehow “break the link” between the NEWS file on the stable branch and the NEWS file on the default branch?

Yes, I also experienced some trouble in the past.

According to the GNU Coding Standards every “package should have a file named NEWS”. But this might be necessary for the final distribution of an Octave release not in the development repo, right?

Maybe we could maintain distinct /etc/NEWS.x files and copy create /NEWS during the release tarball generation :innocent:

I thought maybe the reason this merge is not working properly now is because of this changeset octave: 0ec5eaabaf2c in which I used hg copy NEWS etc/NEWS.7 and then edited the NEWS file. My guess was that it work better if, on the default branch, we used hg rename instead and then created a new NEWS file. But I’ve tried that and it doesn’t seem to work for me. After recreating the NEWS file, changes are still merged from NEWS on stable to both NEWS and etc/NEWS.7 on default.

Maybe a different approach is needed? Could we just have


in the sources and generate the top-level NEWS file when we build a tarball distribution file?

1 Like

ISTR it working more conveniently previously. The respective change when the Octave 7 cycle started was:
octave: f47f9493cb37 (

It doesn’t look much different to me…

In a series of changes starting with cset octave: 0e553bb97d31 NEWS will now be generated from

	$(AM_V_GEN)cp $< $@

This hopefully resolves many NEWS related merging conflicts in the future :slightly_smiling_face:

Thanks. That might indeed improve the mething experience in the future.

However, it looks like you deleted the old NEWS.* files and added new ones with a different name (instead of renaming the existing files). That way, we lost the history of those files (e.g., for hg annotate).
Is there a way to restore that history?

Sorry, I had to add one more cset octave: 4d15a0540ac0 as my testing environment was not clean enough. Luckily we have lots of CI to detect such problems :innocent:

@mmuetzel I think the file history is not gone. Mercurial seems not the best tool to handle file renamings:

When you look at the first changeset and move to its parent, you can still display the previous file log:

Not super convenient indeed. With git you can trace the changes easily:

Edit: Maybe I am a little too spoiled from the renaming auto-detection of git (Octave is the only project I work on with Mercurial). Using Mercurial I read it is better to help by explicitly calling hg rename, thus sorry again for the inconvenience.

I pushed an additional set of changes that essentially does what you did while (hopefully) preserving the history.
I’m not sure if some of the changes you made got lost in these steps. So, please check if there is anything you’d like to push again to the new HEAD.

I do not understand what has been changed now. But things did not fully work out yet: my changes are partially reverted and the history is still not fully tracked by Mercurial :sweat:

Later I can try to fix the changes again. Maybe it is better to accept a partial defeat than pushing another bunch of changes with make things only more complicated and the repo is left now in a bad condition.

Again the root of the trouble is on me for not properly using hg rename (lession hopefully learned).

It works with hg annotate on the stable branch:
octave: etc/ annotate (
And the default branch:
octave: etc/ annotate (

Not sure why the file log shows something different…

Edit: It might be an issue with the web interface. The file history seems to be ok for me locally.

Edit 2: I pushed two of your changes again that were essentially undone by my previous changes:
octave: ce42e027cd40 (
octave: 334797d4cd56 (

I hope we are as close as we can get to a “clean” repository now.

Now I think we are there. Basically, I backed out all of the recent changes and pushed them again in a single cset for stable and default.

My apologies for all the mess in the repo :sweat:

If I understand correctly, hg log only follows file copying and renaming if you use the --follow (or -f) option.

I thought I did the same. And it doesn’t look like that last change made a difference in that respect:
octave: etc/ history (

Edit: Only difference that I can spot at the moment is that I didn’t add .md to the NEWS files before we started to use markdown.

Would it be ok to remove the .md file extension from the NEWS files that aren’t actually markdown? They display unexpectedly when interpreted as markdown.
I’d prefer to do that instead of touching the syntax in those old files.

This is still work in progress. My plan was to keep those file in sync with the ones published on the homepage:

and get auto published by GitHub, GitLab, etc. which is simply cool, I think :sunglasses:

The source is plain editor readable Markdown and the result a great HTML representation.

Do you plan on publishing the old NEWS files with the same mechanism, too? They don’t use markdown syntax and display unexpectedly when treated as such…

Like I said, reformatting those files is still work in progress.

I removed the .md file extension from the NEWS files that don’t use markdown syntax. If you’d like to reformat those old files later, you can add that extension again when that is done.