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

[David Kastrup]

"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.

That way, you'll not accidentally bring stuff back in that Graham (or
someone else) decided to throw out from dev/staging.

-- 
David Kastrup