Re: ChangeLog and commit messages

[Eli Zaretskii]

> From: Po Lu <luangruo@yahoo.com>
> Cc: Eli Zaretskii <eliz@gnu.org>,  emacs-devel@gnu.org
> Date: Mon, 19 Jun 2023 14:51:53 +0800
> 
> Konstantin Kharlamov <hi-angel@yandex.ru> writes:
> 
> > Hmm, it seems it's an SVN workflow, because in git or Mercurial you can't 
> > lock
> > file. I didn't have experience of working with SVN (fortunately, from what 
> > I can
> > tell), but I think if I had to work with it I would use `git-svn`.
> 
> Most VCS have an option to perform locked check-outs of a file.  Git and
> Mercurial are exceptions.
> 
> > Anyway, I kind of wanted to see a commit you have troubles adding a title 
> > for.
> > Judging by your first message here it's the same situation with commits to
> > Emacs, so you can drop some commit hash for example. I kind of can speculate
> > based on the general description of this SVN workflow, but it may be more
> > productive to look at specific cases where such problem arises.
> 
> If you search for ``Update Android port'' in the feature/android branch,
> you will see what I mean.

If your problems are with the feature branch, then I think you are
making your life harder than it needs to be.  Our conventions for
formatting commit log messages don't apply to feature branches.  On
feature branches, the developers are free to format the log messages
as they see fit; the only log message that matters is the one for the
merge-commit which lands the feature branch on master (which you have
to create by hand anyway).

The upshot of all this is that while you are working on a feature
branch:

  . you can use short single-line note-like log messages, which might
    be unclear to anyone but yourself
  . you should generally commit each time when you finish some
    meaningful changeset, so that it could be later reverted without
    complications -- this goes well with short log messages
  . it is futile to use "C-x 4 a"-style log messages, especially for
    changes in files or in functions the branch adds, because in the
    final commit log we only need to see "foo: New file"

This leaves you with the need to come up with a commit log for when
the branch is landed.  That might sometimes be a large job, but it
will be much smaller than the sum total of what you do now.  Moreover,
what you do now will not help you avoid this job, because we do
require3 a meaningful summary log message for when the branch is
merged.