Re: [PATCH 7/7] Track common ancestors of a successful conffiledb merge
sean finney wrote:
> The idea IIRC was that if a merge is likely to have conflicts, having the
> common ancestor of the merge would provide the ability to offer the
> post-merge diffs of the previous merge (to the on disk version as well
> as the old pristine version) could provide further options in the
> new merge resolution.
For repeating a conflict resolution? Unfortunately I don't think it
would work in this form. Imagine a package with a branchy development
history (time flowing left to right):
O --- A
\
\
B
For example, A might be one version in experimental; later the
experiment was discarded, and B is a different version from
experimental (the branchiness is not important to this example by the
way; it just makes my life a little easier. If you prefer, it's
equally good to imagine the history looking like O --- A --- B).
Then we can imagine the following sequence of operations:
- install version O
- modify a configuration file
- upgrade to A. Encounter merge conflicts, fix up the result.
- downgrade back to O (and restore the conffile to its old state).
- upgrade to B. Encounter similar merge conflicts.
It would indeed be nice to reuse the merge resolution by recognizing
what conflict hunks matched up to what content in the upgrade to A.
One way to imagine doing this is to re-create the merge conflict that
occurred then and analyze how the user fixed it up.
Unfortunately keeping a single old pristine version (merge base)
does not help with this. What would happen is the following:
- install version O (the merge base is some old version N).
- modify configuration file.
- upgrade to A (the merge base is O).
- downgrade back to O (the merge base is A)
- try to upgrade to B.
More generally, when upgrading from version X to Y, the details of how
conflicts were resolved in creating the conffile in version X are not
useful. Those conflicts are already resolved --- the upgrade from X
to Y brings new and distinct conflicts.
Alas. To provide such functionality, I think the simplest way would
be to provide a hook to allow some out-of-tree code (for example,
something like git's rerere) to take care of recording the pertinent
information after each conflict resolution. (I say out-of-tree but it
is possible to build it into dpkg, too. To be useful it just would
need a way to remember about multiple upgrades and a way to expire
that information at an appropriate time.)
> Apart from that, I guess it's whatever issues/changes/concerns Guillem
> has in mind.
Yep, will be looking at that next.
Reply to: