[zanata-devel] git cherry-pick and branch management

[Sean Flanigan]

1. Please don't use git cherry-pick in Zanata if you can help it.

If possible, make the fix in the older branch (eg "release"), and merge
it into the newer branch (eg "integration/master").  For bonus points,
make the fix against the commit that introduced the bug in the first
place - "daggy fix".  This ensures that the fix only has one "identity"
in git, and commands like "git branch --contains COMMIT" can work.  This
can be important for QA.

2. If you must use cherry-pick:
(eg to back-port a fix from "master" to "release")
a: *please* use the -x option so that we can tell where the commit
originated.
b: make sure you immediately merge the new commit forward, so that git
knows the commit has been merged.  This makes branch management much
easier, because we don't have to worry about losing changes.

By the way, if you have to use cherry-pick, it is the new COMMIT (after
cherry-picking) which should be reported in bugzilla.  That way we can
use commands like "git branch --contains" or "git merge-base
--is-ancestor" most effectively.


Essentially, what we're aiming for is this:

A. Every commit in legacy should be in release also.
B. Every commit in release should be in integration/master also.



Thanks!

-- 
Sean Flanigan

Senior Software Engineer
Engineering - Internationalisation
Red Hat

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 554 bytes
Desc: OpenPGP digital signature
URL: <http://listman.redhat.com/archives/zanata-devel/attachments/20130430/0cc1887b/attachment.sig>