Re: Moving Emacs 24.3 development to emacs-24 branch soon

[Stephen J. Turnbull]

Eli Zaretskii writes:

 > Actually, I find the graph of emacs-24 to be confusingly obscure.  See
 > the attached screenshots of "bzr qlog", where simple merges from (the
 > old) emacs-24 are now displayed as something utterly weird, and
 > backports from trunk look weirder still.

I don't understand what you find weird or "not simple" about these.
They indicate quite clearly what's happened.  In both cases the theme
is "work on a branch, test, and only when happy merge to mainline."
Yidong made a separate branch for the purpose of merging two public
branches.  Ken'ichi made a "feature" branch to develop some fixes.  If
you don't find that information useful, ignore it.  (Eg, use bzr log
--omit-merges.)  Is there some sense that it gets in your way?

(I had already written the following, but really the above summary is
what's relevant.  But if you're curious about how I interpret the
DAGs, read on.)

In your first screenshot, it seems that at r110121 Yidong simply made
a branch to ensure that any merge screwups didn't make it to trunk.
He then merged emacs-24 into the temporary branch at r110121.1.  He
made no mistakes and upon inspection the merge looked correct (ie, I
suppose he did a test build etc., and inspected the commit log to make
sure no emacs-24-only commits were added (from the word "backport" I
wonder about 107781.350, but I don't have all the context of that
patch).  So he merged the temporary branch back into trunk without
making any new commits himself.  It's possible that he had to fix
merge conflicts, but I would assume if he did it would be noted in the
log.

In the second one, the yellow branch created at r110016 appears to be
a "miscellaneous fix" branch that Ken'ichi is using as a testing
workspace or similar.  So he regularly merges up to trunk head, does
more work, and remerges from the branch to trunk.

I agree the duplicate commit messages do look weird, but every one of
them actually corresponds to a single commit on the branch, then
merged back to the trunk.  It is considered best practice in bzr to
provide a summary of the branch being merged so that bzr log -n1 gives
a "big picture" of the work being merged.  Since Ken'ichi is
committing a single change then merging, I think simply copying the
message makes sense.  If that bugs people, then Emacs could make a
style guide for commit messages that says "If you have multiple
commits, summarize in the merge log.  If there's only one, you can
copy that message, but prepend '(merge) '."  Or something like that.