Re: merge-commits policy

[Stefan Monnier]

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

The same holds for "merge from emacs-23" or any other merge for that matter.

> 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.  As would searching the ChangeLog rather than "bzr log".
Personally I would use C-x v l and/or C-x v g from the texinfo.tex buffer.

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


        Stefan