Merge algorithms

Eli Zaretskii eliz at gnu.org
Thu Sep 16 21:59:36 BST 2010


> Date: Thu, 16 Sep 2010 15:11:57 -0500
> From: John Arbash Meinel <john at arbash-meinel.com>
> CC: Martin Pool <mbp at canonical.com>, aaron at aaronbentley.com,
>   bazaar at lists.canonical.com
> 
> bzr-builddeb has implemented a per-file merger that handles
> debian/changelog files, sorting the contents by the debian revision string.

Thanks.

> > The Right Thing for the merge in this case is very simple: put the
> > lines that are new on the source branch at the beginning of the
> > ChangeLog file, i.e. _before_ all the lines that are new on the target
> > branch.  (The "source" branch is the one _from_ which you merge, and
> > the "target" is the one _onto_ which you merge.)
> > 
> 
> I suggest looking at the above code for inspiration, though I'm not sure
> that your statement is 100% correct in all cases. I'm sure it *isn't* in
> the case of debian => ubuntu merging, because debian may come out with a
> new release that is technically older [by revnumber logic] than the
> latest ubuntu version. As an example, debian may be releasing
> project-1.1 while ubuntu has already upgraded to project-1.2. So debian
> will add project-1.1debian2, while ubuntu has
> project-1.2ubuntu3. The new debian changelog should come grouped with
> the other project-1.1 entries.

The use-case I was talking about is when you merge your feature branch
back into mainline, and then commit.  In that case, it is customary to
have the log entries from the branch be the last in the log, because
the log entries on mainline are supposed to correspond to dates of
commit to mainline, not the dates of commits to the feature branch.

> (and what happens if someone fixes a typo in an old changelog entry, or
> remembers to credit someone, or.... You really do need to parse the
> entries to know what has changed, hence a custom merge is perfectly
> appropriate.)

It's appropriate, but for some reason it refuses to merge the new
entries from the branch and declares them a conflict.  I don't really
understand why it should be a conflict.



More information about the bazaar mailing list