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

[Jeff King <peff@peff.net>]

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

> > 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