Re: git history tracking across renames (and emacs support)

[Basil L. Contovounesios]

Ted Zlatanov <address@hidden> writes:

> On Tue, 10 Jul 2018 18:36:23 +0300 Eli Zaretskii <address@hidden> wrote: 
>
>>> From: Ted Zlatanov <address@hidden>
>
>>> I would appreciate that too. If I need to know what functions were
>>> modified, I look at the diff, which Git makes trivial.
>>> 
>>> Is there any chance of evolving the commit message formatting
>>> requirements to lower the friction of making a commit and reduce
>>> redundancy?
>
> EZ> IMO, what you'd like to have will actually _raise_ the friction
> EZ> (i.e. will be harder to provide) for many contributors, according to
> EZ> my experience of reviewing quite a few patches.
>
> I really don't think the current format is easy for anyone, especially
> new developers. It's also essentially repeating the headers from the
> diff.
>
> Anecdotally, every time I want to make a larger commit with a lot of
> items, it feels to me like paperwork for its own sake and takes up a
> long time.
>
> Let's take a recent example.
>
> commit 2fde6275b69fd113e78243790bf112bbdd2fe2bf
> Author: Basil L. Contovounesios <address@hidden>
> Date:   Mon Jul 9 18:46:33 2018 -0700
>
>     Add predicate proper-list-p
>     
>     For discussion, see emacs-devel thread starting at
>     https://lists.gnu.org/archive/html/emacs-devel/2018-04/msg00460.html.
>     
>     * lisp/subr.el (proper-list-p): New function.
>     Implementation suggested by Paul Eggert <address@hidden> in
>     https://lists.gnu.org/archive/html/emacs-devel/2018-06/msg00138.html.
>     * doc/lispref/lists.texi (List Elements):
>     * etc/NEWS: Document proper-list-p.
>     * lisp/org/ob-core.el (org-babel-insert-result):
>     * lisp/emacs-lisp/byte-opt.el (byte-optimize-if):
>     * lisp/emacs-lisp/cl-macs.el (cl--make-usage-args): Use proper-list-p.
>     * lisp/emacs-lisp/ert.el (ert--proper-list-p): Remove.
>     Replaced by proper-list-p in lisp/subr.el.
>     (ert--explain-equal-rec): Use proper-list-length.
>     * lisp/format.el (format-proper-list-p): Remove.
>     Replaced by proper-list-p in lisp/subr.el.
>     (format-annotate-single-property-change): Use proper-list-p.
>     * test/lisp/emacs-lisp/ert-tests.el (ert-test-proper-list-p):
>     Move from here...
>     * test/lisp/subr-tests.el (subr-tests--proper-list-length):
>     ...to here, mutatis mutandis.
>
> Here's one way to write it more concisely and make it more readable,
> keeping in mind that the diff is part of the same log and is thus going
> to be right below the explanation, and Git usually already *knows* which
> files and functions have been modified. I'd much rather read the second
> version.
>
> commit 2fde6275b69fd113e78243790bf112bbdd2fe2bf
> Author: Basil L. Contovounesios <address@hidden>
> Date:   Mon Jul 9 18:46:33 2018 -0700
>
>     Adds and documents the new predicate function proper-list-p
>
>     Factors out several one-off implementations of the same functionality.
>     For discussion, see emacs-devel thread starting at
>     https://lists.gnu.org/archive/html/emacs-devel/2018-04/msg00460.html.
>
>     Implementation suggested by Paul Eggert <address@hidden> in
>     https://lists.gnu.org/archive/html/emacs-devel/2018-06/msg00138.html.

I haven't been following this thread, so I apologise in advance if the
following comment completely misses the point or has been expressed
before.

Speaking as a relatively new and young Emacs contributor (i.e. one who
has learned to program in the age of Git and GitHub pull requests of the
last handful of years, is largely unfamiliar with and neither married to
nor dependent on older traditions and conventions, and has little to no
experience in maintaining large collaborative free software projects),
one aspect of changelog-style commit messages which I really appreciate
is that they are generally more amenable to fast and precise git-log
search.

In particular, I find 'git log --grep=<pattern>' is often significantly
faster and closer to what I'm looking for than a corresponding
'git log -G<regex>'.

In my fictional ideal world, I could avail of fast, accurate, and dwim
history search without ever having to write a tedious, mechanical
changelog.

In my day-to-day, however, there's nothing inherent in the changelog
style stopping me from writing clearer, less lazy, and human-readable
commit messages.

Just one datum.

-- 
Basil