On Oct 28, 2011, at 3:06 PM, David Kastrup wrote: > "m...@apollinemike.com" <m...@apollinemike.com> writes: > >> On Oct 28, 2011, at 2:38 PM, David Kastrup wrote: >> >>> "m...@apollinemike.com" <m...@apollinemike.com> writes: >>> >>>> On Oct 28, 2011, at 2:11 PM, lilyp...@googlecode.com wrote: >>>> >>>>> >>>>> Comment #8 on issue 1981 by d...@gnu.org: Patch: Adds Scheme >>>>> function for spring constructor. >>>>> http://code.google.com/p/lilypond/issues/detail?id=1981 >>>>> >>>>> You forgot to rebase when pulling from dev/staging. I took the >>>>> liberty of doing that and replacing dev/staging with the result. So >>>>> your commit now is >>>>> 63f43c43a87be99477432e1f3156eac5870b775e >>>>> and dev/staging should be pretty enough for fast-forwarding into >>>>> master again. >>>>> >>>> >>>> It's not that I forgot, it's that I have no clue what I'm doing with >>>> git when things venture outside of the insanely simple. >>>> I did >>>> git checkout dev/staging >>>> git pull >>>> git apply foo.diff >>>> git commit -a -m "This is my commit message." >>>> git push >>>> >>>> Where should I do the rebase, and what should that line look like? >>> >>> In this case, you would have needed >>> git pull -r >>> which rebases your dev/staging on origin/dev/staging (since dev/staging >>> is frequently reset, it does not make sense to keep its history >>> according to your repository available). >>> >>> If your old staging had stuff that was later removed (because of failing >>> regtests or whatever), this stuff will be now in again. >>> >>> So if you are not strictly at origin/dev/staging now, check that >>> everything on top of that is yours and supposed to go in, otherwise do >>> an appropriate hard reset. >>> >>> Instead of applying a diff, you are better off doing git cherry-pick >>> commit-id for getting the stuff into staging. >>> >>> If you have a feature branch, it might be worth doing >>> git fetch >>> git rebase origin/dev/staging feature-branch >>> [Check that everything looks hunky-dory] >>> git push origin HEAD:refs/heads/dev/staging >>> >>> If your feature branch has commits with non-compilable state in it >>> (i.e., before running convert-ly), you want just a single merge commit >>> to end up in staging: >>> git fetch >>> git rebase origin/dev/staging feature-branch >>> git checkout origin/dev/staging >>> git merge --no-ff feature-branch >>> git push origin HEAD:refs/heads/dev/staging >>> >>> Again: before pushing, most definitely use gitk or similar to check that >>> the commit structure you are going to push makes sense: only nicely >>> separated single commits, with the exceptions of merge commits bypassing >>> the mainline if you want to split a feature into several commits with >>> intermittently non-working working tree that should not go into the >>> mainline in order not to disturb git bisect. >>> >> >> Ok. I followed your advice for a push I just made with in-notes. >> Please let me know if this looks correct and sorry in advance if there >> are still any problems! > > input/regression/in-note.ly starts with \version "2.15.15", but VERSION > is at 2.15.17 for the next release from staging. > > You can checkout origin/dev/staging, fix the version (assuming that > your commit is still last), do > commit -C HEAD --amend input/regression/in-note.ly > to meld this fix into your commit. > > git push origin HEAD:refs/heads/dev/staging > will now fail since you are not an ancestor of your original commit > anymore. Try it anyway. > > git push original +HEAD:refs/heads/dev/staging > would _overwrite_ dev/staging, but our repository is set up to not allow > that (how stupid: for staging it would be really useful). > > After double-checking with git-fetch that nobody left anything more in > origin/dev/staging, you can to > > git push origin :refs/heads/dev/staging > git push origin HEAD:refs/heads/dev/staging > > Note that the first line _deletes_ the staging branch. The second > rewrites it from scratch. > > Better not fall asleep between the two commands, or you'll be unpopular. >
Sorry for the oversight. Wouldn't it just be easier to commit a new commit with the change in version number? Cheers, MS _______________________________________________ bug-lilypond mailing list bug-lilypond@gnu.org https://lists.gnu.org/mailman/listinfo/bug-lilypond
