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
rpm -V git gives no output, indicating that the man file has not been corrupted on my system.
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
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?
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?
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 ...
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.
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.
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 ;)
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.
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
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.