Johannes Schindelin <Johannes.Schindelin@xxxxxx> writes: > So essentially, what your cherry-pick'able commits are is a way to store > what rerere would have stored (i.e. the set of merge conflicts together > with their resolution)? If rerere would have stored, I wouldn't have separate band-aid system on top. These fix-up commits are usually on parts that do not get involved in textual conflicts; "rerere" which relies on having textual conflicts (the "shape" of the text in the conflicted region is what lets "rerere" index into its database to find the recorded resolution) wouldn't have stored them and that is fundamental. > If so, what tooling do you have to identify quickly what to cherry-pick, > given merge conflicts? It exactly is the issue I've been trying to find ideal solution for quite a while and not successfully. Here is a sample thread https://public-inbox.org/git/xmqqeft3u0u5.fsf@xxxxxxxxxxxxxxxxxxxxxxxxxxx/#t and every message I mention "merge-fix" is relevant. The current band-aid system punts and indexes the merge-fix changes by merely a branch name. When refs/merge-fix/X exists, what it means is "When branch X is merged to an integration branch, it is likely that the integration branch _already_ has merged an unnamed topic that causes semantic conflicts and requires this fix-up". This needs occasional manual adjustment---e.g. when the topic X turns out to be a lot more stable than the other topic Y that was causing us trouble with semantic conflicts, I may at some point reorder the topics and have topic X advance to 'next' before topic Y does. And when that happens, when I merge X to 'next', because Y is not yet in 'next', I shouldn't apply refs/merge-fix/X (often, an attempt to cherry-pick it on top of a merge of X into 'next' would fail, which would be a bit of safety, but not always). What I should do instead is to rename refs/merge-fix/X to refs/merge-fix/Y immediately before merging X to 'next', so that the cherry-pick is not applied. When rebuilding 'master'->'jch'->'pu' chain, X (now in 'next') will be merged before Y (not in 'next') gets merged, and when it is Y's turn to be merged, the merge-fix I used to apply when merging topic X will be applied. In the ideal world (I think I'm repeating the ideas raised in the thread quoted), the merge-fix database should be indexed with a pair of commit object names (e.g. a step in branch X that adds a new callsite for function frotz() and a step in branch Y that changes the function signature of frotz()), and teach the system to cherry-pick refs/merge-fix/A-B to resolve semantic conflicts, when both commits A and B appears in the integration branch for the first time. And make sure these are kept up-to-date across rebasing of commits A and B. After rebasing the topics X and Y that contained the commits A and B, if they became C and D, the system somehow needs to be able to locate the previous merge-fix that was valid for A-B pair when C-D pair gets merged.
