[Top][All Lists]

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

Re: Issue 1981 in lilypond: Patch: Adds Scheme function for spring const

From: address@hidden
Subject: Re: Issue 1981 in lilypond: Patch: Adds Scheme function for spring constructor.
Date: Fri, 28 Oct 2011 15:55:42 +0200

On Oct 28, 2011, at 3:52 PM, David Kastrup wrote:

> "address@hidden" <address@hidden> writes:
>> On Oct 28, 2011, at 3:18 PM, David Kastrup wrote:
>>> "address@hidden" <address@hidden> writes:
>>>> Sorry for the oversight.  Wouldn't it just be easier to commit a new
>>>> commit with the change in version number?
>>> Sure, that's certainly possible.  However, one of the points of the
>>> staging branch is that mistakes need not get into master.
>>> To make an example for how to do corrections like that, I looked at your
>>> change in order to find something to complain about.  And the version
>>> string was the easiest target...
>>> dev/staging is a moving target.  It should be kept in a state where
>>> fast-forwarding master to it is possible (because that's really what
>>> Patchy can do with good conscience after testing).
>>> But from one moment to the next, it might stop being a proper descendant
>>> of a previous value of dev/staging, and contributors must be prepared to
>>> deal with that: rebasing their own work on top of an old dev/staging on
>>> the rewritten version of dev/staging.
>> Worked like a charm!
>> Thanks for the tip.
> And here is how I recovered after being in your previous version of
> dev/staging:
> Your branch and 'origin/dev/staging' have diverged,
> and have 1 and 1 different commit(s) each, respectively.
> address@hidden:/usr/local/tmp/lilypond$ git rebase origin/dev/staging
> First, rewinding head to replay your work on top of it...
> Applying: Adds in-notes to LilyPond.
> Using index info to reconstruct a base tree...
> Falling back to patching base and 3-way merge...
> Auto-merging input/regression/in-note.ly
> CONFLICT (add/add): Merge conflict in input/regression/in-note.ly
> Failed to merge in the changes.
> Patch failed at 0001 Adds in-notes to LilyPond.
> When you have resolved this problem run "git rebase --continue".
> If you would prefer to skip this patch, instead run "git rebase --skip".
> To restore the original branch and stop rebasing run "git rebase --abort".
> address@hidden:/usr/local/tmp/lilypond$ git diff
> diff --cc input/regression/in-note.ly
> index 1ed0ecc,6e1b8b7..0000000
> --- a/input/regression/in-note.ly
> +++ b/input/regression/in-note.ly
> @@@ -1,4 -1,4 +1,8 @@@
> ++<<<<<<< HEAD
> +\version "2.15.17"
> ++=======
> + \version "2.15.15"
> ++>>>>>>> Adds in-notes to LilyPond.
>  \header {
>    texidoc = "LilyPond does in-notes.  The positioning of these notes can
> address@hidden:/usr/local/tmp/lilypond$ git rebase --skip
> HEAD is now at 84ed591 Adds in-notes to LilyPond.
> Since rebasing replays the patches from _your_ branch on the upstream
> branch, skipping foreign patches that conflict with newer versions of
> themselves is the right thing to do.
> Of course, you should also check the results of the rebase to make sure
> that you did not reintroduce foreign patches from your old staging
> branch into the current one.
> It does make quite a bit of sense to do your own work in a feature
> branch based off origin/master rather than an own copy of staging, and
> just merge or rebase on a freshly fetched origin/dev/staging when you
> are ready for putting it out.

+1.  This is what I used to do with origin/master as well.


reply via email to

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