Date: Wed, 19 May 2021 02:33:46 +0000 From: Alexey Dokuchaev <danfe@freebsd.org> To: Joseph Mingrone <jrm@freebsd.org> Cc: ports-committers@freebsd.org, dev-commits-ports-all@freebsd.org, dev-commits-ports-main@freebsd.org Subject: Re: git: 6464fe05fe9d - main - - Update Unipro UGENE to version 38.1 and thus unbreak - CONFIG defaults to 64-bit mode now, adjust the check Message-ID: <YKR5CvT0ZbiEs93k@FreeBSD.org> In-Reply-To: <868s4b6az4.fsf@phe.ftfl.ca> References: <202105181525.14IFPYMT003113@gitrepo.freebsd.org> <86pmxo56wi.fsf@phe.ftfl.ca> <YKQfDRmDBp0NxB32@FreeBSD.org> <868s4b6az4.fsf@phe.ftfl.ca>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?YKR5CvT0ZbiEs93k>