bugGNU troff - Bugs: bug #54114, QUICK TYPO FIX in tbl(1): `tbl(c)'...


bug #54114: QUICK TYPO FIX in tbl(1): `tbl(c)' should be `tab(c)'

Submitted by:  Michael Witten <mfwitten>
Submitted on:  Thu 14 Jun 2018 05:17:21 AM UTC  
Category:  Preprocessor tbl Severity:  3 - Normal
Item Group:  Documentation Status:  Fixed
Privacy:  Public Assigned to:  G. Branden Robinson <gbranden>
Open/Closed:  Closed Planned Release:  1.22.4

Add a New Comment (Rich Markup)

You are not logged in

Please log in, so followups can be emailed to you.


( Jump to the original submission)

Tue 19 Jun 2018 06:57:30 PM UTC, comment #8: 

No, my friend. You are missing the point. Let's be clear:

  $ git log --reverse -S 'tbl( c )' --format=%H | head -1 |
    xargs git log -1 --format=%H%n%ad
  Mon Jul 21 15:04:55 2014 +0200

An egregious mistake  in the naming of an  option sat prominently
near the top of the man page in question for almost 4 years until
a *passerby* said to himself:

   You know what? I guess I have to be the one to fix this.

   I mean,  I've already figured  out that it's  wrong, and
   there's no  benefit  to me  to worry  about it  further;
   however,  let  me  save  another person  from  the  same

That passerby went through the trouble of finding the repository,
cloning it, locating the error, making and validating the change,
producing a patch with the relevant information, figuring out how
to log into Yet Another  Cumbersome Ticket-Tracker, filling out a
poorly designed  form, uploading the patch,  explaining concisely
and obviously how that patch  should be applied, and taking every
step to make the process of reviewing and incorporating the patch
as convenient as possible for the maintainer.

This passerby wanted just one thing.

All this passerby  wanted in return (and all  this passerby asked
for, both explicitly and unnecessarily) was for his authorship to
be recorded, which is not exactly a tall order for a contribution
to a software project, let along a FOSS project.

And,  no. Injecting  his  name somewhere  in  the commit  message
doesn't count; besides  the fact that doing so  neglects any kind
of official structure, there are  also fellow folk who grace this
world under the  name "Michael Witten". And no.  The patch wasn't
written on 2018-June-16; it  was written on 2018-June-14. (Please
note that git  records not only authorship  information, but also
committership information.)

What makes me  grumpy is not just the  *willful* incompetence (or
maybe  laziness),  but  rather the  *unearned*  indignation  that
inevitably follows not far behind.

Look,  I'm  not the  one  pretending  to  be  a custodian  for  a
software project.  You self-described "maintainers"  have adopted
an indignation that  is undeserved; you fscked up at  the one job
that you yourselves have placed upon your own damn shoulders, and
then you got passive-aggressively  defensive when you dropped it.
Perhaps, that  unwarranted attitude  was lost in  translation for
you in particular, Werner?

As far as my acerbic comment is concerned, I stand by it; heed my
warning or  don't. The only  reason it  stings is because  it has

For instance, your  censure  of  my inadequate social skills, and
your accusation of my victimizing nature, fail to wound my ego or
trigger  any introspection;  such obvious  falsehoods are  like a
fart in the wind.

I wish you and your project the best.

Michael Witten

Michael Witten <mfwitten>
Tue 19 Jun 2018 05:52:54 AM UTC, comment #7: 

Thanks for the detailed reply with useful tips regarding git management, where you obviously excel (and we not).  However, you are completely missing the point.  What makes me grumpy is your lack of social skills.  Even I, being Austrian with German as my mother tongue and usually far more direct than US people in addressing issues, am pissed off by your condescending #4 reply.  Looking around it seems we are not the only victims of your attitude...

In hindsight: was it really necessary to reply like you did?

BTW, even in your `rational' #6 response you are completely irrational in generalizing `the GNU projects', which is utter nonsense.  Again, being Austrian, I'm probably a bit more sensitive than others to generalizations of groups of people, which lead to a rather dark time in history.

Werner LEMBERG <wl>
Project Administrator
Mon 18 Jun 2018 01:29:30 PM UTC, comment #6: 

[rational reply intentionally written in English]

* My report explains "git am".

  The first  thing my bug  report states is  how to use  "git am"
  to  apply  the  patch,  with  the  explicit  reason  being  the
  preservation of the authorship information.

  Why do  you think I  even felt compelled  to do this?  It's not
  because I'm super serious about having this typo fix attributed
  to  me, but  rather because  I  had a  gut feeling  that a  GNU
  maintainer would fsck it up again; well, I nailed it.

* I'd never commit  someone else's work under my  name, no matter
  how small.

  Indeed,  the first  thing  I'd  do as  a  maintainer is  figure
  out  how to  use  my tools  to  preserve authorship  correctly.
  Pretty quickly, I'd  learn at least the  following command line
  arguments for "git commit":


  and probably the following environment variables:


  and  certainly,  I'd  be  intrigued by  a  contributor  who  is
  directing me in precisely how to apply a patch ("Is there some-
  thing I don't know about? Let me look into this.").

* Yes, mistakes happen. Apologize for them to preserve good will.

  One of the most important jobs of a maintainer is to make other
  people want  to do work, virtually  for free; hell, I  even did
  the work of explaining how to  apply a patch properly, so as to
  make the process as convenvient as possible.

  And, you know what?

  Though I'm not suggesting this be done, if I were a maintainer,
  I'd  be more  than  happy to  fix  a mistake  like  this; as  a
  maintainer,  I would  take pride  in  correcting a  bug in  the
  history by inserting an "empty" commit with the correct inform-
  ation (I had to figure out how to do this):

    git checkout master
    git reset --hard HEAD
    git log -1 --format='%H %T' | {
      read head tree
          echo "Correct commit authorship"
          echo "The authorship info for this commit is what"
          echo "should be the authorship info for commit"
          echo "'82d56c12d4e131ec072ad3525d7f683c6acd2261'."
        } | GIT_AUTHOR_NAME='Michael Witten'                  \
            GIT_AUTHOR_EMAIL='mfwitten@gmail.com'             \
            GIT_AUTHOR_DATE='Thu, 14 Jun 2018 05:02:42 +0000' \
              git commit-tree -p "$head" "$tree"
      git reset --hard "$commit"

  Of course, I do NOT want that "fix" actually applied (certainly
  not for a  typo), but as a  maintainer, I'd do it,  not only to
  improve my  understanding of maintaining the  history, but also
  to foster good will rather than alienation.

* It is irritating to contribute to GNU projects.

  Your projects  have lost  a lot of  brainpower over  the years,
  because people have been finding  it way too irritating to make

  Make it enjoyable to contribute.

Michael Witten

Michael Witten <mfwitten>
Sat 16 Jun 2018 07:55:06 PM UTC, comment #5: 

[rant intentionally written in German]

Was soll das?  Warum diese völlig unbegründete Unhöflichkeit?

Er hat Dir eine ehrlich gemeinte Frage gestellt und zugegeben, daß er sich mit git und im speziellen mit »git am« nicht gut auskennt und daher den Patch nicht mit deinen Autor-Attributen versehen hat.  Wie Du weißt, kann man bereits veröffentlichte Commits nicht mehr im Nachhinein modifizieren.

Mißgeschicke passieren.  Hast Du es wirklich nötig, gleich den verbalen Mittelfinger zu zeigen?  Bei so einer Kleinigkeit?

Werner LEMBERG <wl>
Project Administrator
Sat 16 Jun 2018 07:34:26 PM UTC, comment #4: 

Your reply is consistent with GNU's stagnation and the FSF's increasing irrelevance.

Michael Witten <mfwitten>
Sat 16 Jun 2018 01:33:03 PM UTC, comment #3: 

Hi Michael,

I'm not accustomed to using the "git am" command.  I'll certainly read more about it now.

Can you explain to me how the following information constitutes the effacement of "official credit" for your work, or represents a slight upon your contribution?

commit 82d56c12d4e131ec072ad3525d7f683c6acd2261
Author: G. Branden Robinson <g.branden.robinson@gmail.com>
Date:   Sat Jun 16 04:56:33 2018 -0400

    tbl(1): Fix erroneous global option reference.


    * src/preproc/tbl/tbl.1.man: Tell readers that the tab character is set
    with tab(c), not tbl(c).  Noted and corrected by Michael Witten.


    Fixes Savannah #54114.


    Signed-off-by: G. Branden Robinson <g.branden.robinson@gmail.com>


Finally, is it your intention to assert copyright status in a two-character change altering "bl" to "ab"?  If so, I will have to take myself out of the loop and refer this matter to the FSF's general counsel.

G. Branden Robinson <gbranden>
Project AdministratorIn charge of this item.
Sat 16 Jun 2018 12:18:35 PM UTC, comment #2: 

I don't undestand why you didn't apply my patch. I don't understand why you have taken official credit for my work.

In my experience, maintainers of GNU software are the most keen to slight contributors in this way. Is it an attempt to fake copyright consolidation for your copyleft cult?

Michael Witten <mfwitten>
Sat 16 Jun 2018 09:01:17 AM UTC, comment #1: 

Thanks, Michael!

Fixed in 82d56c12d4e131ec072ad3525d7f683c6acd2261.

G. Branden Robinson <gbranden>
Project AdministratorIn charge of this item.
Thu 14 Jun 2018 05:17:21 AM UTC, original submission:  

The tbl(1) man page is incorrect.

Download the attached patch to `/path/to/patch', and apply it with:

    git am /path/to/patch

For your convenience, here is the diff (but please apply the attached patch, as it contains correct authorship information):

diff --git a/src/preproc/tbl/tbl.1.man b/src/preproc/tbl/tbl.1.man
index 3fdaee6e..c52ef4f5 100644
--- a/src/preproc/tbl/tbl.1.man
+++ b/src/preproc/tbl/tbl.1.man
@@ -149,7 +149,7 @@ Cells are separated by a tab character by default.
That can be changed by the
.I global option
-.BI tbl( c ) \fR,
+.BI tab( c ) \fR,
.I c
is an arbitrary character.

Michael Witten <mfwitten>


(Note: upload size limit is set to 16384 kB, after insertion of the required escape characters.)

Attach Files:

Attached Files
file #44366:  00.patch added by mfwitten (679B - text/x-patch)


Depends on the following items: None found

Items that depend on this one: None found


Carbon-Copy List
  • -email is unavailable- added by wl (Posted a comment)
  • -email is unavailable- added by gbranden (Updated the item)
  • -email is unavailable- added by mfwitten (Submitted the item)

    Do you think this task is very important?
    If so, you can add your encouragement to it.
    This task has 0 encouragements so far.

    Only logged-in users can vote.




    Follow 6 latest changes.

    Date Changed by Updated Field Previous Value => Replaced by
    2018-06-16 gbranden StatusIn Progress => Fixed
        Open/ClosedOpen => Closed
    2018-06-16 gbranden StatusNone => In Progress
        Assigned toNone => gbranden
        Planned ReleaseNone => 1.22.4
    2018-06-14 mfwitten Attached File- => Added 00.patch, #44366

    Back to the top

    Powered by Savane 3.6