On 1/16/12 9:26 AM, "Phil Holmes" <m...@philholmes.net> wrote:
> >Before you start thinking about pushing a patch to staging, you >need to ensure you have the correct local branches up to date. >One time only, edit the .git/config file to look like this (there >will be other lines and sections, don't touch these): > >@example >[remote "origin"] > fetch = +refs/heads/*:refs/remotes/origin/* > url = ssh://git.sv.gnu.org/srv/git/lilypond.git >@end example > >Now, each time you want to make a change and push to staging, do >the following: > >@example >git fetch # (to be sure you have the current version of staging) >git checkout origin/staging ># ... make and commit your change ... e.g. with git am patchname >git push origin HEAD:staging >@end example > >Note that this does not work well for complex changes on other >branches - if you're doing this you'll need to have better git >understanding. However, "make your change" could include applying >a patch previously you've made. This set of instructions works great if you are maintaining your work in patches. Getting the latest staging and then applying patches to it before pushing will always work. Of course if your patches are not based on staging, then they may not apply. The current instructions on working with branches in the cg are ideal for working with a staging that may be destroyed at any time. I think that they are sound, and can be effectively used by anybody. Although Graham may not appreciate it, I think I may modify lilygit.tcl to create an advanced mode that readily supports switching branches, posting for review, and pushing to staging. Thanks, Carl _______________________________________________ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
