merge-commits policy (was: bug#8675: lisp_string_width and strings wider than INT_MAX)

[Eli Zaretskii]

This issue came up as a spin-off of discussing the proposed patch for
bug #8675.  I moved the discussion here because it is related to the
procedures contributors are supposed to use when committing to the
master repo.

Here's the beginning, for those who don't read bug-gnu-emacs:

> > Date: Sun, 15 May 2011 22:33:03 -0700
> > From: Paul Eggert <eggert <at> cs.ucla.edu>
> > CC: 8675 <at> debbugs.gnu.org
> > 
> > On 05/15/11 22:30, Eli Zaretskii wrote:
> > >> Date: Sun, 15 May 2011 22:07:36 -0700
> > >> From: Paul Eggert <eggert <at> cs.ucla.edu>
> > >>
> > >> PATCH 3 depends on two obvious patches: PATCH 2 introduces a
> > >> helper
> > >> no-return function string_overflow, and PATCH 1 updates to the
> > >> latest
> > >> version of gnulib.
> > > 
> > > Thanks, but why do these patches come with unrelated changes in
> > > texinfo.tex?
> > 
> > Because that's part of PATCH 1, which updates to the latest version
> > of gnulib.  Gnulib contains texinfo.tex.  PATCH 1 was generated
> > entirely automatically by "make sync-from-gnulib".
> 
> When you merge, could you please make the texinfo.tex update a
> separate commit on the trunk, then?  No one will ever expect to find
> that file in a commit logged as "sync from gnulib", which will make
> forensics more difficult than it needs to (since your commits are
> always merge-commits).

And here's how Stefan replied:

> From: Stefan Monnier <address@hidden>
> Cc: Paul Eggert <address@hidden>,  address@hidden
> Date: Mon, 16 May 2011 13:48:33 -0300
> 
> > When you merge, could you please make the texinfo.tex update a
> > separate commit on the trunk, then?
> 
> Why?

I already explained the reasons in my original message (above),
i.e. that forensics is more difficult.

> > No one will ever expect to find that file in a commit logged as "sync
> > from gnulib",
> 
> I, for one, do.  texinfo.tex is not a file we maintain, so I fully
> expect to find its changes in some kind of "sync from outside" commit.

Well, then maybe replace "no one will ever" with "many people will
not".

However, I think even you will not expect to find that texinfo.tex was
updated in commits such as these two:

  revno: 103360 [merge]
  committer: Paul Eggert <address@hidden>
  branch nick: trunk
  timestamp: Sun 2011-02-20 00:48:52 -0800
  message:
    Merge: Import crypto/md5 and stdint modules from gnulib.
    --------------------------------------------------------
  revno: 103104 [merge]
  committer: Paul Eggert <address@hidden>
  branch nick: trunk
  timestamp: Thu 2011-02-03 11:30:24 -0800
  message:
    merge: allow C code to suppress warnings about ignored return values
  ------------------------------------------------------------

Yes, invoking "bzr log" with the -n0 or --include-merges switch would
have shown that the second one of these two mentions texinfo.tex in
its branch commit.  But these switches makes "bzr log" much slower.
Any bzr command that uses revision specs need special care (e.g.,
using the `before:' keyword) to ensure branch commits aren't missed.
And to find out which branch commit modified texinfo.tex as part of
revision 103360, you need "bzr diff", or other similar tricks.  It's
not rocket science, but it makes the job of finding the relevant
changes harder and more error prone.  Plus, it requires one to have
good control of relatively obscure options.

Thus my request.

More generally, I thought commits to mainline from local branches are
supposed to be one feature at a time.  That is, each changeset
committed to mainline is supposed to be self-contained and not mix
different features and unrelated bugfixes.  If you regard any "sync
from gnulib" as a single self-contained changeset, then at least it
should be committed to mainline separately from other changes.

admin/notes/commits has these instructions, which I thought was
supposed to be followed:

  (0) Each commit should correspond to a single change (whether spread
      over multiple files or not).  Do not mix different changes in the
      same commit (eg adding a feature in one file, fixing a bug in
      another should be two commits, not one).

  (1) Commit all changed files at once with a single log message (which
      in CVS will result in an identical log message for all committed
      files), not one-by-one.  This is pretty easy using vc-dir now.

  (2) Make the log message describe the entire changeset, perhaps
      including relevant changelog entiries (I often don't bother with
      the latter if it's a trivial sort of change).

If that's not the policy, then what _is_ the policy?

As an aside, it looks like the version of texinfo.tex we merge is from
ftp://tug.org/tex/.  But this message recently posted by Karl Berry,
the maintainer of that file:

  http://lists.gnu.org/archive/html/bug-texinfo/2011-04/msg00038.html

indicates that the right place is ftp://ftp.gnu.org/gnu/texinfo/.