Philip Oakley <philipoakley@iee.email> writes: > Maybe have a parallel 'merge' branch that is used (say weekly) to do > trial merges and will essentially record the conflict resolutions while > they are fresh in folks memories. That branch is distinct from, either > of the two main branches, but will act as a filter and a hand rail to > highlight future difficulties." An aside that probably would not directly help Eric, but I know the above workflow helps reasonably well. The 'pu' branch is rebuilt not on top of 'next', but is rebuilt with all topics (including those already in 'next') in flight directly on top of 'master', which serves as a way to anticipate conflicts that will require resolution in the future before the topics can enter 'next' branch. And these resolutions are ... > Also look at 'rerere'. ... remembered in the rerere database (and even trickier ones that rerere cannot handle are recorded in the merge-fix commits, but that is a separate story). When topics are ready to be merged to 'next' and to 'master', the correct resolutions are likely to be known and the result tested in 'pu' and 'next', respectively, for some time already.
