git: 6464fe05fe9d - main - - Update Unipro UGENE to version 38.1 and thus unbreak - CONFIG defaults to 64-bit mode now, adjust the check

[Alexey Dokuchaev]

On Tue, May 18, 2021 at 05:30:39PM -0300, Joseph Mingrone wrote:
> On Tue, 2021-05-18 at 20:09, Alexey Dokuchaev wrote:
> ...
> > It's a known bug in Git, for some reason it does not stop at first \n.
> > Interestingly, cgit web frontend does not exhibit this problem, does
> > it use some smarter form of shortlog?
> 
> > The main point, however, is that commit logs should not contain what
> > can be easily and automatically inferred from the commit itself.  As
> > an example of sanity, have a look at https://freshbsd.org/freebsd,
> > which infers correct commit headers and clearly shows how needlessly
> > noisy those "canonical" logs start to look like if you do things the
> > right way.
> 
> The FreshBSD page seems to be showing full commit logs.

This is not what I was pointing at.  Albeit I find shortlogs utterly
useless, one could still infer path (category/port) information from the
commit and append the first line of the commit log to it.  There is
absolutely no need to *manually* put it in the log, this information
is *already* embedded in the commit and can be extracted automatically,
regardless of the log format.  In fact, if you do put it manually, it
means it could be wrong, either accidentally or maliciously.  If some
particular gitish tool does not infer it, then it should be fixed, not
commit logs pessimized.

> I don't know how cgit implements their log display, but it's not a bug.
> It's a convention.

Convention (which I don't like) is "short\n\nlong" log format; the bug
is that git shortlog does not stop after the first \n, contrary to what
the word "short" means.

./danfe