"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. -- David Kastrup _______________________________________________ bug-lilypond mailing list bug-lilypond@gnu.org https://lists.gnu.org/mailman/listinfo/bug-lilypond
