On 13 May 2013 16:28, Martin Sandve Alnæs <[email protected]> wrote: > On 13 May 2013 17:15, Jed Brown <[email protected]> wrote: >> >> Martin Sandve Alnæs <[email protected]> writes: >> >> > Of course, but in bzr, you could "merge" a range of changesets without >> > the ancestors, which meant applying the patches introduced by those >> > changesets, effectively the same as cherry-picking in git. >> >> I'm not familiar with bzr, but are you talking about "merging" ranges in >> the "Cherrypicking" section here? >> http://doc.bazaar.canonical.com/beta/en/user-guide/adv_merging.html > > > > Yes. From what Garth said I think he tried to do that kind of "merge" with a > single commit and it _seemed_ to work because the ancestors were shared. >
Which is also why I was reasonably confident doing it - there wasn't anything else that could be pulled in. > >> > Jed: so is it _never_ ok to make even simple fixes directly in >> > next/master/maint? >> >> You can make simple fixes (e.g., .gitignore and doc fixes) on 'master' >> or 'maint', but not on 'next' because 'next' is rewound after a release >> (discarding everything that was in 'next', re-merging any topics that >> failed to graduate). The only non-merge commits made directly in 'next' >> should be those reverting something that was later determined to be a >> bad idea or needed to be reworked significantly. > I made a small change to .gitignore that should have gone straight into master, but by accident went into next. The question for me is how to best recover from such an mistake. I'm clear on what can be done, but not clear on what the best approach to recovering from such a mistake is. Maybe just cherry pick and leave a stray commit in next until the next release. Garth > > Ok, thanks. > > Martin _______________________________________________ fenics mailing list [email protected] http://fenicsproject.org/mailman/listinfo/fenics
