[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Issue 1988 in lilypond: Patch: Rename \markuplines to \markuplist (b

From: David Kastrup
Subject: Re: Issue 1988 in lilypond: Patch: Rename \markuplines to \markuplist (before running convert-ly)
Date: Fri, 28 Oct 2011 09:25:02 +0200
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/24.0.90 (gnu/linux)

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

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

           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

reply via email to

[Prev in Thread] Current Thread [Next in Thread]