Re: Issue 1988 in lilypond: Patch: Rename \markuplines to \markuplist (before running convert-ly)

[David Kastrup]

Graham Percival <address@hidden> writes:

> On Fri, Oct 28, 2011 at 08:51:45AM +0200, David Kastrup wrote:
>> Graham Percival <address@hidden> writes:
>> 
>> > Once it's in staging (whether or not it went through a countdown),
>> 
>> I won't put it through another countdown just because of the version
>> number.
>> 
>> 10 minutes or so.
>
> ok, sounds good.  2.15.17 will happen in 20-24 hours.

If master has been tampered with in the meantime, you need to rebase
origin/dev/staging on master with the -p option.

Apparently, this will make the rebase fail at the merge commit with a
message complaining that no option -m has been specified: for
cherry-picking a merge commit, git needs to know the "mainline", the
branch of the merge history that will get followed for HEAD~whatever
references and that consequently is to be used for bisecting.  Better
check with gitk, but the mainline is likely to be the first one (number
1).

So you'll need to do

git cherry-pick -m 1 the-merge-commit-git-rebase-complained-about
git rebase --continue

I have not discovered an option to make -m 1 the default for
cherry-picking inside of a rebase sequence.  Incidentally, what I _did_
discover in the manual pages was the rebase option

       --no-ff
           With --interactive, cherry-pick all rebased commits instead of
           fast-forwarding over the unchanged ones. This ensures that the
           entire history of the rebased branch is composed of new commits.

           Without --interactive, this is a synonym for --force-rebase.

           You may find this helpful after reverting a topic branch merge, as
           this option recreates the topic branch with fresh commits so it can
           be remerged successfully without needing to "revert the reversion"
           (see the revert-a-faulty-merge How-To[1] for details).

which would have been useful to me in the past.

-- 
David Kastrup