Bug 485161 - git man page not displayed correctly
git man page not displayed correctly
Status: CLOSED ERRATA
Product: Fedora
Classification: Fedora
Component: git (Show other bugs)
11
i386 Linux
low Severity medium
: ---
: ---
Assigned To: Todd Zullinger
Fedora Extras Quality Assurance
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2009-02-11 18:32 EST by Robin Green
Modified: 2013-01-10 05:30 EST (History)
6 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2009-06-28 19:47:23 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Robin Green 2009-02-11 18:32:31 EST
Description of problem:
The git-reset man page displays with weird characters in it. It looks like some characters have not been interpreted correctly.

Version-Release number of selected component (if applicable):
git-1.6.1.3-1.fc11.i386

How reproducible:
Always

Steps to Reproduce:
1. man git-reset

Actual results:
Here is a sample of the output:

               $ git commit ...
               $ git reset --soft HEAD^      ▓fB(1)▓fR
               $ edit                        ▓fB(2)▓fR
               $ git commit -a -c ORIG_HEAD  ▓fB(3)▓fR

           ⌂sp ▓fB1. ▓fRThis is most often done when you remembered what you just committed is incomplete, or you misspelled your commit message, or both.
           Leaves working tree as it was before "reset".  ⌂br ▓fB2. ▓fRMake corrections to working tree files.  ⌂br ▓fB3. ▓fR"reset" copies the old head
           to .git/ORIG_HEAD; redo the commit by starting with its log message. If you do not need to edit the message further, you can give -C option instead.

           See also the --amend option to git-commit(1).  ⌂br

       Undo commits permanently

               $ git commit ...
               $ git reset --hard HEAD~3   ▓fB(1)▓fR

           ⌂sp ▓fB1. ▓fRThe last three commits (HEAD, HEAD^, and HEAD~2) were bad and you do not want to ever see them again. Do not do this if you have
           already given these commits to somebody else. (See the "RECOVERING FROM UPSTREAM REBASE" section in git-rebase(1) for the implications of doing so.)
           ⌂br

       Undo a commit, making it a topic branch

               $ git branch topic/wip     ▓fB(1)▓fR
               $ git reset --hard HEAD~3  ▓fB(2)▓fR
               $ git checkout topic/wip   ▓fB(3)▓fR

           ⌂sp ▓fB1. ▓fRYou have made some commits, but realize they were premature to be in the "master" branch. You want to continue polishing them in a
           topic branch, so create "topic/wip" branch off of the current HEAD.  ⌂br ▓fB2. ▓fRRewind the master branch to get rid of those three commits.
           ⌂br ▓fB3. ▓fRSwitch to "topic/wip" branch and keep working.  ⌂br

       Undo add

               $ edit                                     ▓fB(1)▓fR
               $ git add frotz.c filfre.c
               $ mailx                                    ▓fB(2)▓fR
               $ git reset                                ▓fB(3)▓fR
               $ git pull git://info.example.com/ nitfol  ▓fB(4)▓fR

Expected results:
Something more sensible-looking.

Additional info:
man-1.6f-14.fc11.i386
groff-1.18.1.4-16.fc10.i386
Comment 1 Robin Green 2009-02-11 18:35:32 EST
rpm -V git gives no output, indicating that the man file has not been corrupted on my system.
Comment 2 Todd Zullinger 2009-02-11 18:51:41 EST
This is a known problem.  I reported it upstream¹, but no one seems to know the cause.  It seems to have started with F10, where xmlto is newer than on F9.  Any help or ideas would be appreciated.  Maybe the xmlto maintainers can help?

¹ http://article.gmane.org/gmane.comp.version-control.git/105589
Comment 3 Ondrej Vasik 2009-02-12 08:02:42 EST
Strange, could build that manpage without problems (and with expected look) on my machine with latest xmlto (in fact 0.0.22 RC :) - but it seems to work with 0.0.21 as well), I have latest docbook-style-xsl, older groff (groff-1.18.1.1-11.1). Which version of docbook-style-xsl was used for build?
Comment 4 Todd Zullinger 2009-02-12 12:20:32 EST
Ondrej, thanks for taking a look.

docbook-style-xsl-1.74.0-6.fc11 is what was pulled in to the build root.  The mock logs for this build are at:

http://kojipkgs.fedoraproject.org/packages/git/1.6.1.3/1.fc11/data/logs/i386/

This has happened since sometime during the F10 rawhide cycle.  I thought when I looked at it then that the only package which differed was xmlto.  But I could easily be wrong about that.  I surely don't have a great understanding of the doc tool chain. :)

So are you saying that you can perform a mock build and not get these odd characters?  Or is it perhaps due to some difference between your system and what's in the F10/F11 repos?
Comment 5 Ondrej Vasik 2009-02-13 04:58:55 EST
No, not mock build - just local build on my machine (based on FC-6. many things from rawhide) - so too many differences from mock/koji build. Will try to check what's wrong ...
Comment 6 Ondrej Vasik 2009-03-24 12:11:25 EDT
Sorry for few weeks delay... Issue seems to be caused by DOCBOOK_XSL_172=YesPlease ... without that variable defined, xmlto builds git-reset manpage without troubles. Otherwise Callout multibyte replacement in manpage-1.72.xsl (which is used instead of callouts.xsl in the case that DOCBOOK_XSL_172 is defined. Could you please which minor manpage issues were fixed by defining that DOCBOOK_XSL_172 variable when we have 1.74.3 now ? IMHO those issues should be fixed other way.
Comment 7 Todd Zullinger 2009-03-24 13:24:19 EDT
Thanks for looking at this Ondrej.

The issue fixed by using the DOCBOOK_XSL_172 definition is described at http://article.gmane.org/gmane.comp.version-control.git/105589.  The summary:

    For example, in git-diff.1, without DOCBOOK_XSL_172, I see:

                   .ft C
                   $ git diff            (1)
                   $ git diff --cached   (2)
                   $ git diff HEAD       (3)
                   .ft

    With DOCBOOK_XSL_172, I get this:

                   $ git diff            ▓fB(3)▓fR
                   $ git diff --cached   ▓fB(2)▓fR
                   $ git diff HEAD       ▓fB(3)▓fR

This just came up on the git list again today, with Chris Johnsen sending a patch series which aims to fix things up a bit.  Perhaps that thread and patch series will make more sense to you than it does to me? :)

    http://thread.gmane.org/gmane.comp.version-control.git/114417

If you have a chance to look at that and see if it might help fix these issues, it would be most appreciated.  Thanks again for taking a look.  Let me know if I can help dig up any other pointers to help you out.
Comment 8 Ondrej Vasik 2009-03-25 12:04:17 EDT
I guess there was already discussion about those .ft in manpage upstream - see http://thread.gmane.org/gmane.comp.version-control.git/56147/focus=56153 or http://kerneltrap.org/mailarchive/git/2007/7/19/252065/thread 

Generally - with docbook-style-xsl >= 1.72 you'll get \&.ft instead of having just .ft ...

Something like sed -i s/\&\.ft/\.ft/g <manpage> for every manpage after build should workaround the .ft problem better way than defining DOCBOOK_XSL_172 . I know it's silly, but it's quickest ;)
Comment 9 Todd Zullinger 2009-04-04 19:01:28 EDT
Thanks again Ondrej.  I added a simple sed to workaround the .ft issue and dropped the DOCBOOK_XSL_172 usage until a better solution is found.  I've yet to look at the patch series that Chris Johnsen worked on.  It's possible that may help eventually.

I've built git-1.6.2.2-1.fc11 for rawhide.  If anyone notices these man page issues still or if undefining DOCBOOK_XSL_172 has caused other problems please speak up.
Comment 10 Bug Zapper 2009-06-09 07:17:31 EDT
This bug appears to have been reported against 'rawhide' during the Fedora 11 development cycle.
Changing version to '11'.

More information and reason for this action is here:
http://fedoraproject.org/wiki/BugZappers/HouseKeeping
Comment 11 Todd Zullinger 2009-06-28 19:47:23 EDT
I believe this is reasonably fixed in git-1.6.2.2-1.fc11, with an even cleaner upstream fix enabled in the rawhide 1.6.3.x packages.  Feel free to re-open this is problems persist.

Note You need to log in before you can comment on or make changes to this bug.