bug-lilypond
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: David Kastrup
Subject: Re: Issue 1981 in lilypond: Patch: Adds Scheme function for spring constructor.
Date: Fri, 28 Oct 2011 14:38:08 +0200
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/24.0.90 (gnu/linux)

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

-- 
David Kastrup




reply via email to

[Prev in Thread] Current Thread [Next in Thread]