From sflaniga at redhat.com Mon Apr 29 23:31:25 2013 From: sflaniga at redhat.com (Sean Flanigan) Date: Tue, 30 Apr 2013 09:31:25 +1000 Subject: [zanata-devel] git cherry-pick and branch management Message-ID: <517F02CD.20204@redhat.com> 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: