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

[address@hidden]

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.

Cheers,
MS