On 2010-01-17, Graham Percival wrote: > Patrick, > > I'm a bit confused by some of the changes to the git commands for > release/unstable. Doesn't > git merge release/unstable > produce the ugly (and pointless) "merge remote branch" in the git > history for master? I'd rather avoid that, and I thought that > git cherry-pick release/unstable > would do get the changes (as long as there's only one commit) without > producing the "merge" message. That said, I must admit that getting > all changes would be handy for special cases, such as having > translators making last-minute changes before 2.14. > > I don't care if release/unstable has all those messages -- actually, > I'd *rather* have them there -- but I don't see the value of clogging > up master.
It's a trade-off. Using `git cherry-pick' will leave unnecessary duplicate commits in git history, and it takes more time if you have to cherry-pick 5 commits. Using `git merge' saves time in that you can merge *all* commits at the tip of release/unstable with one command, it does not leave duplicate commits, but it leaves one harmless merge commit [1]. [1] In case of a "fast-forward" merge, where release/unstable is identical to master except for the commits at the tip, a merge commit will not be created. So it's up to you. I'm not really bothered by the merge commits, since we see them all the time when lilypond/translation is merged into master. Thanks, Patrick _______________________________________________ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
