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? _______________________________________________ calligra-devel mailing list calligra-devel@kde.org https://mail.kde.org/mailman/listinfo/calligra-devel
