Re: Please don't use revision numbers on commit messages (and elsewhere).

[Thien-Thi Nguyen <ttn@gnuvola.org>]

[-- Attachment #1: Type: text/plain, Size: 1012 bytes --]

() Óscar Fuentes <ofv@wanadoo.es>
() Fri, 01 Apr 2011 02:20:26 +0200

   It is actually informative, although it makes difficult to pinpoint the
   mentioned revision or to answer the question "is the mentioned revision on
   branch X?" which is automatic when you have a revision id.

To dereference a DATE-TITLE pair to a VCS commit the VCS needs to be able to
grep for DATE or TITLE or both in its (internal) commit log representation.
It's an extra step, true, and might be difficult if the VCS is lame.  Likewise
for localizing the commit to a branch.

   A different issue is to convince people to write proper commit messages,
   with the first line acting as the commit title. But that is another
   battle.

All it takes is for the Emacs maintainers to promote the practice from IWBN to
required.  I think concurrent to such a move should be to publish tools to make
the ChangeLog(s) -> VCS commit message flow less balky.  FWIW, i attach some
sketches (that i find useful) here.


[-- Attachment #2: changelog-to-vcs-commit-message-flow.el --]
[-- Type: application/emacs-lisp, Size: 3513 bytes --]

[-- Attachment #3: Type: text/plain, Size: 1031 bytes --]


Example flow:
(0) Munge source in file src/foo.c,
    related docs in file doc/foo.texi.

(1) C-x C-f src/ChangeLog RET
    C-c C-a TITLE RET
    foo.c (func): Change. RET RET
    C-x C-s
    C-x C-k RET

(2) C-x C-f doc/ChangeLog RET
    C-c C-a M-p RET
    foo.texi (functionality): Change. RET RET
    C-x C-s
    C-x C-k RET

(3) initiate commit sequence, specifying files:
      src/ChangeLog
      src/foo.c
      doc/ChangeLog
      doc/foo.texi
    => end up in buffer in Log Edit mode

(4) C-c C-d        ; git-scan-log-buffer-and-insert-commit-log
    tweak aesthetics (paragraph order, primarily)
    C-c C-c        ; log-edit-done
    C-c C-M-r      ; revert-some-buffers

This example assumes the details of each change fits in my head, which often
is not the case.  More typically, there is a series of ‘vc-diff’ invocations
prior to (1) and (2).  I sometimes (very rarely) interleave (0) and (1)/(2).
Anyway, the point is that (3) and (4) take little thought/effort to perform.