Re: merge-commits policy

[Eli Zaretskii <eliz@gnu.org>]

> From: Stefan Monnier <monnier@iro.umontreal.ca>
> Cc: eggert@cs.ucla.edu,  emacs-devel@gnu.org
> Date: Tue, 17 May 2011 10:42:32 -0300
> 
> >   revno: 103104 [merge]
> >   committer: Paul Eggert <eggert@cs.ucla.edu>
> >   branch nick: trunk
> >   timestamp: Thu 2011-02-03 11:30:24 -0800
> >   message:
> >     merge: allow C code to suppress warnings about ignored return values
> >   ------------------------------------------------------------
> 
> The same holds for "merge from emacs-23" or any other merge for that matter.

Except that emacs-23 is a public branch which can be examined
directly, unlike private branches that cannot.

> > 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.
> 
> Exactly.

Exactly: harder.

> As would searching the ChangeLog rather than "bzr log".

Unfortunately, only some of these updates are reflected in
doc/misc/ChangeLog, and some aren't, so this is unreliable.

> Personally I would use C-x v l and/or C-x v g from the texinfo.tex buffer.

"C-x v l" takes ages for veteran files (because texinfo.tex was
"cvs mv"ed, it appears to have been born relatively recently, so it is
spared this problem).  To be efficient, you need to run "bzr log" for
a certain range of revisions.

"C-x v g" is fine only the first time.  Once you find the latest
revision that modified some line, and need to see the previous
revisions that modified the same line, you need to find the exact
revision number and use "-r before:", or else you will miss some of
the change history, e.g. if there were more than one change on the
branch before it was merged.

Like I said: possible, but harder.

> > 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.
> 
> That would make sense, yes.  Although in the case of gnulib, most
> "syncs" happen because we import yet another module, so it's OK to do
> both "import foo module" and "sync" at the same time, but indeed, the
> commit message should indicate that a sync with gnulib took place.

Thanks, I hope this is acceptable.