Hi Junio, On Tue, 13 Mar 2018, Junio C Hamano wrote: > Johannes Schindelin <Johannes.Schindelin@xxxxxx> writes: > > > 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. > > [... detailed explanation of the current "band-aid" system...] Thank you for the very thorough account. I have been struggling with this, too, even chatting to Michael Haggerty about this at the Contributors' Summit (where I missed you a lot). He pointed me to a blog post of his about the very interesting concept of "obsolete markers" in Hg: http://softwareswirl.blogspot.de/2013/05/obsolete-markers-in-mercurial.html Granted, that concept really makes most sense for rebase, but I wonder whether the concept could be extended to help your (and my) use case of frequently-changing targets (for me, it is more rebase targets, for you it is merge targets). It would probably be implemented using commit notes, to allow for bidirectional mappings. Ciao, Dscho > > 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. > >
