Re: proper handling of release/unstable

[Patrick McCarty]

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