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 Darcs takes a radical approach in this regard, allowing all patches to commute until they collide and must be resolved, thus imposing an ordering. > 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. Here is an example from git.git: $ git log --first-parent --no-merges master..next commit 5a288150a9a5a2b1788c28935493846b4ec436a5 Author: Junio C Hamano <[email protected]> Date: Mon Apr 15 12:33:28 2013 -0700 Revert "Merge branch 'kb/status-ignored-optim' into next" This reverts commit 0c12ed9e12dfdc88a9d4c3075551cf4b28077cc6, reversing changes made to 201fed22362e68a2639341fa5ca25ecf66d4e573. And here's the story of why it was reverted: http://mid.gmane.org/[email protected] _______________________________________________ fenics mailing list [email protected] http://fenicsproject.org/mailman/listinfo/fenics
