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

[address@hidden]

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!

Cheers,
MS