Merge algorithms
Andrew Bennetts
andrew.bennetts at canonical.com
Sun Nov 7 23:11:10 GMT 2010
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...
More information about the bazaar
mailing list