On 13/05/13 16:15, Jed Brown 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
To avoid potential confusion here: there is *no* _conceptual_ difference between merges and cherry-picks in git and bzr: in both cases a _merge_ takes 2 branch heads and combines them in a new commit. Both branches remain untouched i.e. their commit ids (SHAs) are stable. A _cherry-pick_ takes a (range of) commit(s) and applies them as a (range of) new commit(s) on top of the current branch tip. The commits are _rewritten_ i.e. their commit ids (SHAs) _change_. There is no way around this because in both bzr and git ancestry is part of the commit. So when merging a branch from which you have previously cherry-picked one or several commits these will inevitably appear in the history twice. In git you have the option to rebase a branch instead of merging it and thereby avoid this replication. There *is* a difference in _terminology_ and imho bzr gets it wrong by allowing to cherry-pick with the merge command (by virtue of -r and -c) and thereby conflating two conceptually completely different operations. It is mentioned in the docs that Jed references, but the distinction is not clear enough. git has a dedicated cherry-pick command, or you can use interactive rebase to the same effect. Florian > 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]
smime.p7s
Description: S/MIME Cryptographic Signature
_______________________________________________ fenics mailing list [email protected] http://fenicsproject.org/mailman/listinfo/fenics
