On 8/22/09 12:11 PM, "Marc Hohl" <address@hidden> wrote:
Carl Sorensen schrieb:
On 8/22/09 3:47 AM, "Marc Hohl" <address@hidden> wrote:
[moved from -user]
According to Neil's proposals and Carl's annotations, I created a patch
to enhance the automatic polyphony:
<< ... \\ .. >> constructs can now be used within
\DrumStaff, \TabStaff and \Staff constructs, without to
explicitly inserting placeholders.
I send it as a gzipped file, because otherwise thunderbird changes the
line endings
from UNIX to DOS.
Since I am not allowed to push directly, please check this patch.
Pushed, thanks. I'm sorry that I was slow on this; I've been away on travel
with virtually no computer time.
No problem; there were some spurious reverts from another patch - I don't
know why this happed, but I definitely need to learn more about git ;-)
Here's what I recommend (I didn't used to do this, but it seems to be a
better way to work).
1) When it's time to start work on a new feature, create a new branch:
git branch newfeature
git checkout newfeature
2) When the new feature is working properly, get all of the changes into a
single commit that describes the differences between your new feature and
the master that it started from.
git rebase -i master
If your master has been updated in the meantime, you'll need to find the
SHA1 ID of the start of the branch newfeature. This is easily done with
gitk. Once you have the SHA1 ID, you do
git rebase -I SHA1-ID-of-the-parent-of-branch-newfeature
3) Now go back to master, and make sure it's up to date:
git checkout master
git pull
4) Now apply the changes to master by cherry-picking the commit with the
latest changes:
git cherry-pick newfeature
5) Now create the patch:
git format-patch origin/master
This should allow you to create a patch with just your changes.
There are also ways to do this that require fewer git commands, but I
recommend this method because it seems to be understandable to the novice.