Re: [PATCH 7/7] Track common ancestors of a successful conffiledb merge
On Fri, May 06, 2011 at 03:24:47AM -0500, Jonathan Nieder wrote:
> Ah, now the memories come back! I find the "While this may not have an
> immediate benefit" mentioned above convincing. I am not happy about
> storing extra data that does not seem very relevant, just in case.
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.
Granted, there's no code that actually makes use of it, so the motivation
is pretty thin for applying it instead of keeping it around somewhere
out-of-tree for if-and-when the support was implemented.
> Everything else in the series looks almost done already. This one
> might have been more of an RFC.
I think it was based on feedback from either buxy or mrvn or both. Not
at all essential for the previous patches, just making room for more
options later.
> Thanks and sorry it took so long to get back to this series. Will
> think more and test drive it a little. Thoughts?
Sounds like a plan. Apart from making sure the rebase is still valid, the
two biggest concerns I'd have were (a) that it's doing fsync related stuff
correctly w.r.t. decisions in dpkg after that point in time and (b) the
multiarch support is correct (I think pkg:arch should suffice, right?).
Apart from that, I guess it's whatever issues/changes/concerns Guillem
has in mind.
Thanks for taking the effort of reviving this.
sean
Reply to: