On Oct 28, 2011, at 3:52 PM, David Kastrup wrote: > "[email protected]" <[email protected]> writes: > >> On Oct 28, 2011, at 3:18 PM, David Kastrup wrote: >> >>> "[email protected]" <[email protected]> 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. > dak@lola:/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". > > dak@lola:/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 > dak@lola:/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 _______________________________________________ bug-lilypond mailing list [email protected] https://lists.gnu.org/mailman/listinfo/bug-lilypond
