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
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?
Merging changes in the
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
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
etc/NEWS.7 on default.
Maybe a different approach is needed? Could we just have
... etc/NEWS.7 etc/NEWS.8 ...
in the sources and generate the top-level
NEWS file when we build a tarball distribution file?
ISTR it working more conveniently previously. The respective change when the Octave 7 cycle started was:
octave: f47f9493cb37 (gnu.org)
It doesn’t look much different to me…
In a series of changes starting with cset octave: 0e553bb97d31
NEWS will now be generated from
NEWS: etc/NEWS.$(OCTAVE_MAJOR_VERSION).md $(AM_V_GEN)cp $< $@ .PHONY: NEWS
This hopefully resolves many
NEWS related merging conflicts in the future
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
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
@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
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).
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.
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
If I understand correctly,
hg log only follows file copying and renaming if you use the
I thought I did the same. And it doesn’t look like that last change made a difference in that respect:
octave: etc/NEWS.7.md history (gnu.org)
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
- octave/NEWS.6.md at default · gnu-octave/octave · GitHub
- etc/NEWS.6.md · default · GNU Octave / octave · GitLab
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.