Git policy: git merge or git cherry-pick

[jaham at gmx.net]

On Monday 31 January 2011 14:27:50 Lukast dev wrote:
> Hello,
> 
> I would like to have your opinion about the preferable and consistent way
> of merging of the code from the features branches we have into master.
> 
> There are more ways:
> 1. git cherry-picking
> a) cherrypick single commits
> b) produce one squashed patch for master and commit it
> 
> 2. git merge
> 
> We discussed about it a little, but I think we need more arguments for the
> decision.
> 
> boud:
> o cherry-picking gives the nicest history I think
> about merge
> o but then the development branch should never be deleted, otherwise
> we have one big commit that nobody can every bisect anymore and never
> figure out the history of
> o if you are going through master trying to find a particular commit
> that broke something -- you get big mega commits again
> 
> sebsauer:
> o cherry-pick'ing is useful if you have only 1-2 commits you like to
> take over else, if you like to take over a range or everything, then
> just merge. That's at least how I do it :)
> 
> Zagge:
> o git merge
> 
> CyrilleB
> o personnaly I go for merging
> o then in the master history you get one commit that correspond to the
> new feature, and if you want more details you can follow the history
> of that commit
> o boud: I'd still like the commit message to have the log, though
> (example git merge --log origin/words-toc-korinek-tvrdy )
> 
> slangkamp
> o rebase should also be possible in some cases
> 
> 
> Jan, how did you merged your gluepoints branch?

Well I intended to simply merge my branch back to master and then push. But 
there were problems with the anongit out of sync with git.kde.org. So it did 
not let me push. Then I tried different things and with the help of Peter 
Simonsson got it to work. So if I remember right I did the following:
git checkout master
git merge flake-odf-gluepoints...
git pull --rebase
git push

Ciao Jan