Merge algorithms

[Andrew Bennetts]

Eli Zaretskii wrote:
> > Date: Sat, 06 Nov 2010 11:11:16 +0200
> > From: Eli Zaretskii <eliz at gnu.org>
> > 
> > Thanks again for this nice feature.  Given enough testing and positive
> > feedback from others, I would suggest to make it part of bzrtools.
> 
> A question about this plugin: will it be used when I "bzr update" in a
> bound branch?  If so, perhaps it would be a good idea to define an
> alias for "update" to use --no-plugins, because ChangeLog files
> updated from upstream can be expected to have modifications in
> existing entries, which this plugin ignores.  WDYT?

Yes, it would be triggered by “bzr update”.  That's an interesting
situation.  I think a shell alias to do
“BZR_DISABLE_PLUGINS=changelog_merge bzr update” is probably an okay
interim solution for you if you don't want the plugin for that case.  (I
don't think “bzr alias” would work for this case, --no-plugins is
processed too early.)

Keep in mind that update is not intrinsically different to merge from
bzr's point of view[1], and I'm not sure that it should be much
different from your point of view either.  e.g. consider “if I have
local branch with a new changelog entry, and I merge in the latest
trunk, then I'd like my changelog entries to be automatically moved to
the top.”  You can s/branch/checkout/ and s/merge in/update to/ and the
statement is still true.  But perhaps there's something specific about
your workflow that means there is an important difference for you.  I
suppose you merge and update from different branches... perhaps that's
the key difference?

Hmm.  I have some fuzzy ideas here, but I'm not sure they're at a point
where I can articulate them clearly or even be confident they make
sense.  So instead I'm going to just dump out a list of bullet points
and see if a coherent picture emerges:

 * IIRC the expected failure mode of “ignoring” modifications is that
   both versions of the entry will occur.
 * that failure mode is possibly easy to catch by hand by glancing at
   the diff?
 * it's probably not too hard to make the plugin detect most
   modifications to existing entries.  e.g. if BASE->OTHER appears to
   delete one entry and add one entry, and a byte-based (rather than the
   default line-based) diff finds say > 80% of bytes in common then it's
   likely to be a modification (fixing a typo, or crediting an extra
   name, or something).
 * if you can detect modifications then it's not hard to preserve them.
 * it probably would be reasonable for the merge_file_content hook to
   have access to some sort of hint about whether this is a merge or
   update operation.
 * a hackish way to do that would be to make the plugin decorate
   cmd_update (or cmd_merge)... yuck.
 * a nicer way might be to make sure update uses nicer labels than
   “THIS” and “OTHER” internally (e.g. for inline conflict markers,
   there's a bug report about that somewhere), e.g. “TREE” and “MASTER”
   or something, and then use those labels to infer if this is an update
   or a merge (or potentially something else from another plugin).
 * or maybe that would be conflating presentation issues with
   behavioural issues.

Not especially coherent, but I think that does cover the next areas I'd
be inclined to work on (in bzr and the plugin).  :)

-Andrew.

[1]  Well, if you have local commits *and* uncommitted changes, then
     update is actually like two merges...