Actually my change 4df59e3e0f3543cb5d93eedbe737735fc7613ad3 introduced a regression in definition list management. Take the following snippet:
git-submodule(1)
================
The 'update' procedures supported both from the command line as well as
through the `submodule.<name>.update` configuration are:
checkout;; the commit recorded in the superproject will be
checked out in the submodule on a detached HEAD.
+
If `--force` is specified, the submodule will be checked out (using
`git checkout --force`), even if the commit specified
in the index of the containing repository already matches the commit
checked out in the submodule.
rebase;; the current branch of the submodule will be rebased
onto the commit recorded in the superproject.
The last definition is cut into two lines with v0.62 whereas it was correctly concatenated by v0.61.
I have to agree that asciidoc is lacking proper syntax definition and that git developpers used all possible combinations of styles, but this change is very disruptive among the source code of git manpages. Does anybody experience the same issue?
Actually my change 4df59e3e0f3543cb5d93eedbe737735fc7613ad3 introduced a regression in definition list management. Take the following snippet:
The last definition is cut into two lines with v0.62 whereas it was correctly concatenated by v0.61.
I have to agree that asciidoc is lacking proper syntax definition and that git developpers used all possible combinations of styles, but this change is very disruptive among the source code of git manpages. Does anybody experience the same issue?