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

[address@hidden]

On Oct 28, 2011, at 3:06 PM, David Kastrup wrote:

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

Sorry for the oversight.  Wouldn't it just be easier to commit a new commit 
with the change in version number?

Cheers,
MS