Merge algorithms

[Eli Zaretskii]

> Date: Mon, 8 Nov 2010 10:11:10 +1100
> From: Andrew Bennetts <andrew.bennetts at canonical.com>
> Cc: bazaar at lists.canonical.com
> 
> 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.)

Alas, “BZR_DISABLE_PLUGINS=changelog_merge bzr update” won't work on
Windows.  But using --no-plugins is also a solution (even less
typing), so it's not a catastrophe.

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

That's true.  Would it be possible for the plugin to detect that no
local changes are present, and fall back on the default merge
algorithm in that case?  Would that be a good idea?

> But perhaps there's something specific about
> your workflow that means there is an important difference for you.

There's nothing fancy in my workflows: the bound branches are for the
mainline, and the local branches are for developing features that are
later merged into the bound branch and committed upstream.  You are
right that "bzr up" when I have local changes should preferably use
the changelog_merge plugin.  But when I have no local changes, I'd
prefer the default merge.

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

Thanks.  Yes, I already use diff to make sure I don't inadvertently
screw up the ChangeLog files by using the plugin.  I think I will run
with it for a while and see if I get any problems, and if so, how
often.  Then perhaps we will be wiser when we discuss possible
solutions.