Re: [PATCH 1/2] gitk: align the commit summary format to the documentation

On Mon, Aug 29, 2016 at 11:17:19AM -0700, Junio C Hamano wrote:

quoted

While it may be easier to read due to the extra mark-up, the resulting
text where such a quotation appears does not flow well, IMO. A commit
message text that references another commit reads more fluently
without the quotes around the summary line because the quoted text is
not so much a quotation that must be marked, but a parenthetical
statement.

I absolutely welcome the proposed change to gitk, because I always
edit out the double-quotes.

I think that is highly subjective, and as you very well may know,
I've been referring to commits without double-quote pair, and have
an obvious bias for something I am used to ;-)

I do not see the "" as introducing a quotation.  I just view it as
very similar to the "" in the following sentence:

    The commit whose title is "foo bar" did not consider there is
    also need to consider baz.

The whole thing is inside () pair, so I agree that with or without
"" pair, it is possible to see where the title ends.  So I do not
have a strong opinion either way.

I have an alias which produces similar output, without the double-quotes
(probably because I stole it from you originally).

I have noticed over the years that the output is occasionally ugly when
the commit names have parentheses themselves. E.g.:

  $ git config alias.ll
  !git --no-pager log -1 --pretty='tformat:%h (%s, %ad)' --date=short

  $ git ll 7e97e10
  7e97e10 (die(_("BUG")): avoid translating bug messages, 2016-07-26)

  $ git ll fa90ab4
  fa90ab4 (t3404: fix a grammo (commands are ran -> commands are run), 2016-06-29)

Adding quotes can help with that. OTOH, I think it just introduces the
same problem with a different character. E.g.:

  $ git ll be00b57
  be00b57 (provide an initializer for "struct object_info", 2016-08-11)

  $ git llq be00b57
  be00b57 ("provide an initializer for "struct object_info"", 2016-08-11)

Perhaps one could write a script to find a custom pretty non-conflicting
delimiter for each case, but I don't know if it's worth the effort. :)

-Peff