On 1/4/19, Werner LEMBERG <[email protected]> wrote: > Please tag the release – and please add tags for older releases also > that are not hidden in mini-branches; this would enormously help in > navigating with gitk and similar programs.
I've added a tag "texinfo_6_5_90" for this prerelease, although I don't know if it will be useful to keep tags for all the prereleases in the long term. Maybe it will be useful to see what has changed since the last prerelease. The tags for the older releases were created in the svn to git conversion. I have looked through the history with "gitk --all" and by "mini-branch" I think you mean that the tag is on a new commit in a branch of its own. The tag needs to be moved to the parent commit and the previously tagged commit to become unreferenced. I expect this is because svn didn't have a separate concept of tags from branches. I have gone through the entire history with gitk, and created new tags for each of the releases with new names, e.g. texinfo-6.2, and deleted the old tags with names like texinfo_6_2. I've removed the "oldmaster" branch which what was left over from a previous conversion to git (done about 10 years ago). You may still have tags like texinfo_6_2 in your version of the repository. You may have to delete them yourself with e.g. "git tag -d texinfo_6_2". The revision tagged "texinfo_4_8" was on its own branch and the commit there makes it look like it is actually texinfo 4.9. The commit for release 4.8 was earlier. The ChangeLog entry for the texinfo 4.9 release was added on the master branch (in svn, called the "trunk") on 2007-07-01 (e9cd40a2c976ee8a67c43d2f705348f9d7459b08). I have tagged the real commit for 4.8 as "texinfo-4.8". Texinfo 4.9 was mainly to change to GPLv3, and may not have included all the changes that were made between December 2004 and June 2007. I have left it as a separate, short branch with the final commit tagged "texinfo-4.9". I'd also like to get rid of the gsoc-2017 branch. Ideally by merging it with the "master branch", although the work on the gsoc-2017 branch exists already in the master branch, just without the full history. I'm not sure what the best way is to include this history: maybe by renaming the "js/" subdirectory on the master branch, merging in the gsoc-2017 branch to the master branch (assuming this can be done without conflicts), and applying the extra commits that have occured on the master branch since then.
