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

[David Kastrup]

"address@hidden" <address@hidden> writes:

> On Oct 28, 2011, at 2:38 PM, David Kastrup wrote:
>
>> "address@hidden" <address@hidden> writes:
>> 
>>> On Oct 28, 2011, at 2:11 PM, address@hidden wrote:
>>> 
>>>> 
>>>> Comment #8 on issue 1981 by address@hidden: 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.

-- 
David Kastrup