On Sat, Nov 2, 2013 at 2:34 PM, Satish Balay <[email protected]> wrote:
> On Fri, 1 Nov 2013, Jed Brown wrote: > > > Satish Balay <[email protected]> writes: > > > > > On Fri, 1 Nov 2013, Satish Balay wrote: > > > > > >> > The reason I had to merge all that stuff into saws was that saws > > >> > could not merge into next because those branches so changed > > >> > next. I had to merge them into saws before I could get saws into > > >> > next. > > > > Peter forgot what had been released to 'next' and rebased after merging, > > leading to two copies of the earlier commits. I think that is the > > reason for much of this confusion. > > Should 'prbrune/sf-sfbasicops' and 'prbrune/mat-matcolor' be cleaned > up to remove the merge between the 'rebased' and 'non-rebased' > variants of the branches - before the changes got into master? Jed mistakes prbrune/sf-sfbasicops with prbrune/snes-qnscaling, which was unrelated and my bad. It came to the fore because it made clearing up someone merging next into a branch even nastier. I'm pretty sure that I didn't rebase sf-sfbasicops or mat-matcolor after merging them to next, so these things shouldn't exist. The issue is that prbrune/mat-matcolor didn't get your update to prbrune/sf-sfbasicops, and Barry merged the prior without the updated latter. I had merged prbrune/sf-sfbasicops into prbrune/mat-matcolor because I wrote it *specifically* so that I could do things in prbrune/mat-matcolor. I had not realized that Satish had updated it and did not remerge, so barry got the old copy when merging mat-matcolor in. - Peter > Satish >
