#492 Git repo lacking tags

[jfbu]

I updated my docutils git clone (from url = git://repo.or.cz/docutils.git), did git pull --tags which fetched tags such as docutils-0.21.2. Then I started git bisect to research some issue but could not understand HEAD was seemingly thousands of commits ahead of docutils-0.21.2. In output of git log --oneline I indeed found much more recent releases, but none of these releases have git tags (which would normally show here).

4530fc43e FIX test no longer break on missing pil
f344d4daf releasing 0.21.2
323957acb Version 0.21.2
af87152e6 stale comment
aebceea6e Reconcile Docutils DTD and Document Tree documentation.
76ae9eec4 man utf8 output uses normal "-" char(45)
5aaa62b8e Uncomment classifiers for Georgian and Catalan (Valencian) languages.
fa86933d7 Small test speedup/simplification.
d10ff72f9 Make effect of centre-aligning figures visible in functional HTML text.
8218b2e47 Avoid dependency of functional tests on PIL/Pillow.
e6069cf76 Prevent test failure due no Pillow or Pillow version above 10.3.
fb9a9421d Remove duplicate test case.
d3fdd821f Do not exclude "test/functional/output/" from the source package.
e85d5159f Fix test failure if tests are started from docutils/docutils.
46db2819c Fix test failure with pygments >= 2.14.
6729e38e3 version 0.21.2b.dev
f83dac7cf release 0.21.1
64d4b0dd8 rough log of trying to install sdist from test.pypi
64733c201 Release 0.21.1 (sdist rerelease)

I am surely missing the obvious... (I dimly remember years ago having had already problems with tags on this project, which I think was simply due to me not having done git pull --tags...).

[Günter Milde]

Docutils 0.21.2 is indeed the last release.
And yes, there are a lot of commits after this - a new release is due once remaining issues are settled.

[Adam Turner]

a new release is due once remaining issues are settled

At an appropriate time, I would be happy to help make the release, if useful -- an effort to increase our bus factor perhaps! @grubert has written a very comprehensive set of notes in release.txt & releasing-log.txt to follow!

A

[jfbu]

Hello, but docutils-0.21.2 is not resolving to f344d4daf but to ab29cf78ae24

docutils$ git log --oneline f344d4daf..HEAD | wc -l
     201
docutils$ git log --oneline docutils-0.21.2..HEAD | wc -l
    9344

??

git log -1 f344d4daf
commit f344d4dafcd68cc9c315a4700b5f0efb5dc2e9e7
Author: grubert <grubert@929543f6-e4f2-0310-98a6-ba3bd3dd1d04>
Date:   Tue Apr 23 19:10:06 2024 +0000

    releasing 0.21.2


    git-svn-id: http://svn.code.sf.net/p/docutils/code/trunk@9651 929543f6-e4f2-0310-98a6-ba3bd3dd1d04

[Günter Milde]

I don't know why you get a different result, however, on https://repo.or.cz/docutils.git/tags the tag for 0.21.2 seems to be correctly set:

commit ab29cf78ae24a9970d9884de40926dceb855bd32
[...] Tue, 23 Apr 2024 20:55:21 +0200 (23 18:55 +0000)

[jfbu]

I git cloned again with https://repo.or.cz/docutils.git not git protocol and got (as expected) the same result.

Notice that ab29cf78ae24a9 is indeed the doctuils-0.21.2 tag but it is not the commit or one of the commits in recent history referring to 0.21.2 release.

$ git log --oneline --grep 0.21.2
0353066fb Fix headers for release 0.21.2
f344d4daf releasing 0.21.2
323957acb Version 0.21.2
6729e38e3 version 0.21.2b.dev

It is as if all docutils-... tags refer to some other branch, and the origin remote does contain many branches other than master but none has a name which seems encouraging to me to try out. The 0.21.2 release seems to about 200 commits back in history, not 9344 commits. So we can't use docutils-... prefixed tags for bisecting.

If I count commits separating docutils-0.21.2 from master HEAD:

$ git log --oneline docutils-0.21.2...master | wc -l
   15385

It looks as if all these tags are on a separate "release" branch which I do not see ats available at my check out.

When I diff between master HEAD and such tags, I see in particular that there is one less layer of docutils/ nesting. Maybe there is some business of a git sub-module (but that exceeds greatly my git knowledge). In brief the tags seem to belong to some other .git structure but somehow are visible from the public svn-to-git mirror repo.

[jfbu]

The parent of docutils-0.21.2 refers to the same revision as a more direct ancestor in master branch:

docutils$ git log -1 docutils-0.21.2~
commit b43eb031ecb2de7d2d1a5e4d160ebe15a0f9a7f0
Author: grubert <grubert@929543f6-e4f2-0310-98a6-ba3bd3dd1d04>
Date:   Tue Apr 23 18:54:26 2024 +0000

    Version 0.21.2


    git-svn-id: http://svn.code.sf.net/p/docutils/code/trunk/docutils@9649 929543f6-e4f2-0310-98a6-ba3bd3dd1d04

$ git log -1 323957acb
commit 323957acb17369d38bd31c81dfe543ae46ae9113
Author: grubert <grubert@929543f6-e4f2-0310-98a6-ba3bd3dd1d04>
Date:   Tue Apr 23 18:54:26 2024 +0000

    Version 0.21.2


    git-svn-id: http://svn.code.sf.net/p/docutils/code/trunk@9649 929543f6-e4f2-0310-98a6-ba3bd3dd1d04

These are the two same commits but they have distinct SHAs and in master branch I see the second one not the first one. The git-svn-id however always refers to ba3bd3dd1d04 i.e. to the actually tagged commits (the parent of the annotated tag itself).

All I am lacking is the branch where this ba3bd3dd1d04 belongs, because it is not in master branch.

[jfbu]

Sorry for one more, but I went too fast. No there is a difference between the git commit messages. The first one (the one tagged by docutils-0.21.-2) contains

git-svn-id: http://svn.code.sf.net/p/docutils/code/trunk/docutils@9649 929543f6-e4f2-0310-98a6-ba3bd3dd1d04

whereas the one in master branch (a direct ancestor to master tip) contains

git-svn-id: http://svn.code.sf.net/p/docutils/code/trunk@9649 929543f6-e4f2-0310-98a6-ba3bd3dd1d04

i.e. former has code/trunk/docutils@9649 and latter has code/trunk@9649.

[Günter Milde]

Thank you for the extensive analysis.
It seems some non-standard setup or handling of either the upstream SVN repo or the git-svn version provided in repo.or.cz is causing errors. (In my repo.or.cz checkout, all tags are broken, too.)

Caveat: the repository in repo.or.cz is a 3rd party contribution, so we cannot change things there.
Rather, we shall move the upstream SVN repo to a Git version and pay attention to correctly convert tags.

[Adam Turner]

Rather, we shall move the upstream SVN repo to a Git version and pay attention to correctly convert tags.

Over the last week or so I have made a series of improvements the reposurgeon conversion process [r9856] -- I now consider this "done". Next to look at is migrating & preserving history for the issue tracker.

A

[jfbu]

For a real life example where tags would have helped see this Sphinx comment. There are no tags associated to releases prior to 0.10 (EDIT: I was wrong here sorry! I did not scroll enough output of git tag on my small screen) and one has to search manually for appropriate commit messages and then check them out. And for tags since 0.10, with the exception of 0.14, they are as reported seemingly annotating some "mirrored" history, which has the commits but with other SHAs and are not direct ancestors of current master tip. For example revision 5862 has two associated commits:

$ git checkout docutils-0.10
$ git log --grep @5862
commit 59d5b34c2692d494a7bb3d680eb681c8ebbcb42e
Author: milde <milde@929543f6-e4f2-0310-98a6-ba3bd3dd1d04>
Date:   Fri Jan 30 13:37:26 2009 +0000

    latex2e writer: backwards compatible implementation of failsave custom roles

    git-svn-id: https://docutils.svn.sourceforge.net/svnroot/docutils/trunk/docutils@5862 929543f6-e4f2-0310-98a6-ba3bd3dd1d04

and

$ git checkout master
$ git log --grep @5862
commit 472ada29b7003d67d955b9ad71c9e94f3156a048
Author: milde <milde@929543f6-e4f2-0310-98a6-ba3bd3dd1d04>
Date:   Fri Jan 30 13:37:26 2009 +0000

    latex2e writer: backwards compatible implementation of failsave custom roles

    git-svn-id: https://docutils.svn.sourceforge.net/svnroot/docutils/trunk@5862 929543f6-e4f2-0310-98a6-ba3bd3dd1d04

but you can't find both at same time, and the latter is as shown the one you find on master branch and then it is not an ancestor of the docutils-0.10 tag.