On 15/06/2020 10:51, Sergey Organov wrote: > Philip Oakley <philipoakley@iee.email> writes: > > > [...] > >> Also look at 'rerere'. > 'rerere' is a superb feature, but isn't it local? If so, how could it > help for collaboration? What's the idea? Is there a way to share > 'rerere'? I saw this (rerere) is two parts. First was to ensure Eric was aware of it as a possible capability for use by the 'merge manager', and others, so that they didn't loose sight of their conflict resolutions for the time when the 'big merge window' came around. E.g. So a dev could do a local fix based on their rerere database and then send a patch to the merge manager indication their approach to the resolution. Meanwhile, second, at the moment the rerere database is 'local', mainly, as I understand it because of the number of context lines a local user has chosen (hence not immediately portable). I personally believe that it should be possible to some how exchange resolutions without that pre-optimisation of the context line choice. I had a look back at the old rerere script and that had small fingerprints of each resolution stored in the database (at least as I read it). However when I look at the modern rerere database it looks like it has full pre & post images, rather than just the conflicts, so I'm not yet sure what's really happening (i.e. I haven't dived into the c code). A possibly more sensible approach (to exchanging resolutions) is simply to do the merge, without commit, then save that merge as if it's a single side commit (with the other merge parent listed in the commit message), and that commit can then be pushed/pulled etc and a variant of `rerere train` can be used to recreate the local database. In a sense the fake merge (why not a proper merge) is a variant of a stash where you aren't wanting to pollute the branch trees with this extra 'flotsam'. Philip >
