Merge or Cherry-Pick?

[Thiago Macieira]

On Monday, 31 de January de 2011 23:34:39 Arno Rehn wrote:
> I guess that won't quite work when there are commits specific to 4.6 in the
> 4.6 branch that shouldn't end up in master. And it clutters history with
> tons of merges.

Then let's solve the problem by not having anything specific to 4.6. If it 
belongs in the stable release, it belongs in the next stable release too. 

If you need to do a quick hack in 4.6, then do it, merge it to master, then fix 
it properly in master. But rather not do quick hacks... do it properly once 
and for all.

As for the tons of merges, they aren't that many. And they are for the greater 
good.

> Personally I'd go with 'Commit to master, cherry-pick in 4.6'.
> (Feature branches are a different thing).

I find that bad. A cherry-pick is a new commit. It's impossible with tools like 
git tag --contains and git branch --contains to find all instances of a commit.

Git was designed for branches and merges. Let's use it.

-- 
Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
  Senior Product Manager - Nokia, Qt Development Frameworks
      PGP/GPG: 0x6EF45358; fingerprint:
      E067 918B B660 DBD1 105C  966C 33F5 F005 6EF4 5358
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 190 bytes
Desc: This is a digitally signed message part.
URL: <http://mail.kde.org/pipermail/kde-core-devel/attachments/20110201/9ff789a8/attachment.sig>