harmonics and slides II

classic Classic list List threaded Threaded
10 messages Options
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

harmonics and slides II

Patrick Schmidt-3
Hi Carl,

here is a revised patch for http://codereview.appspot.com/3590041/. I  
don't know whether it's possible to merge the new patch with the old  
one on rietveld... I used lily-git.tcl to make this patch. Obviously  
all my snippet-files weren't added automatically. I didn't know that.  
So I attached them to this email. Do I have to use git for these kind  
of tasks? What do I have to do to upload all of this to rietveld  
without messing anything up?

BTW: I didn't manage to write a scheme function to automatically  
adjust length and thickness of glissandi in Voice and TabVoice  
contexts. Sorry for that.

Today I posted a bug report concerning \hideNotes in tablature. It  
affects one of the attached snippets.

Thanks for any help to improve.

patrick











0001-harmonics-and-slides-II.patch (5K) Download Attachment
tablature-open-string-harmonics.ly (1K) Download Attachment
tablature-fretted-string-harmonics.ly (1K) Download Attachment
tablature-slides.ly (710 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: harmonics and slides II

Marc Hohl

Am 19.12.2010 18:20, schrieb Patrick Schmidt:
> Hi Carl,
>
> here is a revised patch for http://codereview.appspot.com/3590041/. I
> don't know whether it's possible to merge the new patch with the old
> one on rietveld... I used lily-git.tcl to make this patch. Obviously
> all my snippet-files weren't added automatically. I didn't know that.
> So I attached them to this email.
Hi Patrick,
> Do I have to use git for these kind of tasks?
I think so.
> What do I have to do to upload all of this to rietveld without messing
> anything up?
Files that didn't exist before have to be added by
git add <path/to/new.file>

But I am not sure how this will interact with lily-git.tcl.
>
> BTW: I didn't manage to write a scheme function to automatically
> adjust length and thickness of glissandi in Voice and TabVoice
> contexts. Sorry for that.
>
> Today I posted a bug report concerning \hideNotes in tablature. It
> affects one of the attached snippets.
>
> Thanks for any help to improve.
Your patch look very good - one small correction perhaps?

+@lilypond[verbatim,quote]
+ratioHarmonics = {
+  \ottava #1
+  \harmonicByRatio #1/2<g\3 b\2 e'\1>4
+  \harmonicByRatio #1/3<g\3 b\2 e'\1>4
+  \harmonicByRatio #1/4 { g8\3 b8\2 e'4\1 }
+}

I would add \harmonicByRatio #2/3<g\3 b\2 e'\1>4
as well just to make sure that frets beyond the 12th can be accessed
by this method.

Regards,

Marc


>
> patrick
>
>
>
>
>
>



Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: harmonics and slides II

Patrick Schmidt-3

Am 19.12.2010 um 20:21 schrieb Marc Hohl:

>
> Am 19.12.2010 18:20, schrieb Patrick Schmidt:
>> Hi Carl,
>>
>> here is a revised patch for http://codereview.appspot.com/ 
>> 3590041/. I don't know whether it's possible to merge the new  
>> patch with the old one on rietveld... I used lily-git.tcl to make  
>> this patch. Obviously all my snippet-files weren't added  
>> automatically. I didn't know that. So I attached them to this email.
> Hi Patrick,
>> Do I have to use git for these kind of tasks?
> I think so.
>> What do I have to do to upload all of this to rietveld without  
>> messing anything up?
> Files that didn't exist before have to be added by
> git add <path/to/new.file>
>
> But I am not sure how this will interact with lily-git.tcl.
Is it still possible to use git after having made a patch with lily-git?

>>
>> BTW: I didn't manage to write a scheme function to automatically  
>> adjust length and thickness of glissandi in Voice and TabVoice  
>> contexts. Sorry for that.
>>
>> Today I posted a bug report concerning \hideNotes in tablature. It  
>> affects one of the attached snippets.
>>
>> Thanks for any help to improve.
> Your patch look very good - one small correction perhaps?
>
> +@lilypond[verbatim,quote]
> +ratioHarmonics = {
> +  \ottava #1
> +  \harmonicByRatio #1/2<g\3 b\2 e'\1>4
> +  \harmonicByRatio #1/3<g\3 b\2 e'\1>4
> +  \harmonicByRatio #1/4 { g8\3 b8\2 e'4\1 }
> +}
>
> I would add \harmonicByRatio #2/3<g\3 b\2 e'\1>4
> as well just to make sure that frets beyond the 12th can be accessed
> by this method.
I wanted to keep the snippet as small as possible. That's why I  
created a reference for the selected snippets (tablature-open-string-
harmonics.ly). It contains all eight ratios. It's supposed to be some  
sort of look-up table for LilyPond users...

Thanks for your help

patrick



Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: harmonics and slides II

Marc Hohl
Am 19.12.2010 20:42, schrieb Patrick Schmidt:
>
> [...]
>> But I am not sure how this will interact with lily-git.tcl.
> Is it still possible to use git after having made a patch with lily-git?
Yes, but I hope Carl will join in this discussion, because he did a lot
of work for
the lily-git.tcl programm, so he probably can give you better advice.

>>>
>>> BTW: I didn't manage to write a scheme function to automatically
>>> adjust length and thickness of glissandi in Voice and TabVoice
>>> contexts. Sorry for that.
>>>
>>> Today I posted a bug report concerning \hideNotes in tablature. It
>>> affects one of the attached snippets.
>>>
>>> Thanks for any help to improve.
>> Your patch look very good - one small correction perhaps?
>>
>> +@lilypond[verbatim,quote]
>> +ratioHarmonics = {
>> +  \ottava #1
>> +  \harmonicByRatio #1/2<g\3 b\2 e'\1>4
>> +  \harmonicByRatio #1/3<g\3 b\2 e'\1>4
>> +  \harmonicByRatio #1/4 { g8\3 b8\2 e'4\1 }
>> +}
>>
>> I would add \harmonicByRatio #2/3<g\3 b\2 e'\1>4
>> as well just to make sure that frets beyond the 12th can be accessed
>> by this method.
> I wanted to keep the snippet as small as possible. That's why I
> created a reference for the selected snippets
> (tablature-open-string-harmonics.ly). It contains all eight ratios.
> It's supposed to be some sort of look-up table for LilyPond users...

Ok, I see your point. I made my proposal just to show users at first
glance that other fractions are possible
(without adding *all* possibilities, of course), but probably that's not
necessary here, so just forget about
my comment.

Regards,

Marc




Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: harmonics and slides II

Carl Sorensen
In reply to this post by Patrick Schmidt-3



On 12/19/10 10:20 AM, "Patrick Schmidt" <[hidden email]> wrote:

> Hi Carl,
>
> here is a revised patch for http://codereview.appspot.com/3590041/. I
> don't know whether it's possible to merge the new patch with the old
> one on rietveld... I used lily-git.tcl to make this patch. Obviously
> all my snippet-files weren't added automatically. I didn't know that.
> So I attached them to this email. Do I have to use git for these kind
> of tasks? What do I have to do to upload all of this to rietveld
> without messing anything up?

git-cl takes care of the changes -- no problem.

Simply do

git add Documentation/snippets/new/my-new-snippet

before doing

git commit -a


>
> BTW: I didn't manage to write a scheme function to automatically
> adjust length and thickness of glissandi in Voice and TabVoice
> contexts. Sorry for that.

No problem.

>
> Today I posted a bug report concerning \hideNotes in tablature. It
> affects one of the attached snippets.

This is probably a layer issue.  Hopefully we can get it sorted this week.

Thanks,

Carl



Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: harmonics and slides II

Patrick Schmidt-3

Am 20.12.2010 um 18:19 schrieb Carl Sorensen:

>
>
>
> On 12/19/10 10:20 AM, "Patrick Schmidt" <[hidden email]> wrote:
>
>> Hi Carl,
>>
>> here is a revised patch for http://codereview.appspot.com/3590041/. I
>> don't know whether it's possible to merge the new patch with the old
>> one on rietveld... I used lily-git.tcl to make this patch. Obviously
>> all my snippet-files weren't added automatically. I didn't know that.
>> So I attached them to this email. Do I have to use git for these kind
>> of tasks? What do I have to do to upload all of this to rietveld
>> without messing anything up?
>
> git-cl takes care of the changes -- no problem.
>
> Simply do
>
> git add Documentation/snippets/new/my-new-snippet
>
> before doing
>
> git commit -a
>
>
Hm, this is what I did:

pls:~ PLS$ cd lilypond-git/
pls:~/lilypond-git PLS$ git add Documentation/snippets/new/tablature-
open-string-harmonics.ly
pls:~/lilypond-git PLS$ git add Documentation/snippets/new/tablature-
fretted-string-harmonics.ly
pls:~/lilypond-git PLS$ git add Documentation/snippets/new/tablature-
slides.ly
pls:~/lilypond-git PLS$ git commit -a
Created commit 5226ca8: Selected snippets harmonics and slides II
  3 files changed, 172 insertions(+), 0 deletions(-)
  create mode 100644 Documentation/snippets/new/tablature-fretted-
string-harmonics.ly
  create mode 100644 Documentation/snippets/new/tablature-open-string-
harmonics.ly
  create mode 100644 Documentation/snippets/new/tablature-slides.ly
pls:~/lilypond-git PLS$ git cl issue 3590041
Command "git config rietveld.server" failed.
You must configure your review setup by running "git cl config".
pls:~/lilypond-git PLS$ git cl config
Rietveld server (host[:port]) [codereview.appspot.com]:
CC list: [hidden email]
Tree status URL:
ViewVC URL:
pls:~/lilypond-git PLS$ git cl issue 3590041
Issue number: 3590041 (http://codereview.appspot.com/3590041)
pls:~/lilypond-git PLS$

I can't see the new patch on rietveld. Where did I go wrong?
>>
>> BTW: I didn't manage to write a scheme function to automatically
>> adjust length and thickness of glissandi in Voice and TabVoice
>> contexts. Sorry for that.
>
> No problem.
Thanks! :-(
>
>>
>> Today I posted a bug report concerning \hideNotes in tablature. It
>> affects one of the attached snippets.
>
> This is probably a layer issue.  Hopefully we can get it sorted  
> this week.
Thanks,
patrick
>
> Thanks,
>
> Carl
>



Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: harmonics and slides II

Carl Sorensen



On 12/20/10 11:16 AM, "Patrick Schmidt" <[hidden email]> wrote:

>
>
> Am 20.12.2010 um 18:19 schrieb Carl Sorensen:
>
>>
>>
>>
>> On 12/19/10 10:20 AM, "Patrick Schmidt" <[hidden email]> wrote:
>>
>>> Hi Carl,
>>>
>>> here is a revised patch for http://codereview.appspot.com/3590041/. I
>>> don't know whether it's possible to merge the new patch with the old
>>> one on rietveld... I used lily-git.tcl to make this patch. Obviously
>>> all my snippet-files weren't added automatically. I didn't know that.
>>> So I attached them to this email. Do I have to use git for these kind
>>> of tasks? What do I have to do to upload all of this to rietveld
>>> without messing anything up?
>>
>> git-cl takes care of the changes -- no problem.
>>
>> Simply do
>>
>> git add Documentation/snippets/new/my-new-snippet
>>
>> before doing
>>
>> git commit -a
>>
>>
> Hm, this is what I did:
>
> pls:~ PLS$ cd lilypond-git/
> pls:~/lilypond-git PLS$ git add Documentation/snippets/new/tablature-
> open-string-harmonics.ly
> pls:~/lilypond-git PLS$ git add Documentation/snippets/new/tablature-
> fretted-string-harmonics.ly
> pls:~/lilypond-git PLS$ git add Documentation/snippets/new/tablature-
> slides.ly
> pls:~/lilypond-git PLS$ git commit -a
> Created commit 5226ca8: Selected snippets harmonics and slides II
>   3 files changed, 172 insertions(+), 0 deletions(-)
>   create mode 100644 Documentation/snippets/new/tablature-fretted-
> string-harmonics.ly
>   create mode 100644 Documentation/snippets/new/tablature-open-string-
> harmonics.ly
>   create mode 100644 Documentation/snippets/new/tablature-slides.ly
> pls:~/lilypond-git PLS$ git cl issue 3590041

Right here, you just type

git-cl upload master

The issue number is related to your git branch.


You never specify the issue number.  The issue number is associated with a
branch, is assigned automatically by git-cl, and is found in

.git/config

HTH,

Carl



Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: harmonics and slides II

Patrick Schmidt-3

Am 20.12.2010 um 19:31 schrieb Carl Sorensen:

>
>
>
> On 12/20/10 11:16 AM, "Patrick Schmidt" <[hidden email]> wrote:
>
>>
>>
>> Am 20.12.2010 um 18:19 schrieb Carl Sorensen:
>>
>>>
>>>
>>>
>>> On 12/19/10 10:20 AM, "Patrick Schmidt" <[hidden email]> wrote:
>>>
>>>> Hi Carl,
>>>>
>>>> here is a revised patch for http://codereview.appspot.com/ 
>>>> 3590041/. I
>>>> don't know whether it's possible to merge the new patch with the  
>>>> old
>>>> one on rietveld... I used lily-git.tcl to make this patch.  
>>>> Obviously
>>>> all my snippet-files weren't added automatically. I didn't know  
>>>> that.
>>>> So I attached them to this email. Do I have to use git for these  
>>>> kind
>>>> of tasks? What do I have to do to upload all of this to rietveld
>>>> without messing anything up?
>>>
>>> git-cl takes care of the changes -- no problem.
>>>
>>> Simply do
>>>
>>> git add Documentation/snippets/new/my-new-snippet
>>>
>>> before doing
>>>
>>> git commit -a
>>>
>>>
>> Hm, this is what I did:
>>
>> pls:~ PLS$ cd lilypond-git/
>> pls:~/lilypond-git PLS$ git add Documentation/snippets/new/tablature-
>> open-string-harmonics.ly
>> pls:~/lilypond-git PLS$ git add Documentation/snippets/new/tablature-
>> fretted-string-harmonics.ly
>> pls:~/lilypond-git PLS$ git add Documentation/snippets/new/tablature-
>> slides.ly
>> pls:~/lilypond-git PLS$ git commit -a
>> Created commit 5226ca8: Selected snippets harmonics and slides II
>>   3 files changed, 172 insertions(+), 0 deletions(-)
>>   create mode 100644 Documentation/snippets/new/tablature-fretted-
>> string-harmonics.ly
>>   create mode 100644 Documentation/snippets/new/tablature-open-
>> string-
>> harmonics.ly
>>   create mode 100644 Documentation/snippets/new/tablature-slides.ly
>> pls:~/lilypond-git PLS$ git cl issue 3590041
>
> Right here, you just type
>
> git-cl upload master
OK, I did that:

pls:~/lilypond-git PLS$ git cl upload master
This branch is associated with issue 3590041. Adding patch to that  
issue.
No output from ['git', 'diff', '--no-ext-diff', '--full-index',  
'master', '-M']

I still can't see any changes on rietveld. I made all the revisions  
in a fresh repository. Is that a problem?

>
> The issue number is related to your git branch.
>
>
> You never specify the issue number.
But this is recommended in the section on revisions in the CG
> The issue number is associated with a
> branch, is assigned automatically by git-cl, and is found in
>
> .git/config
>
I really have to come to grips with git. This information manager  
scares the hell out of me. I always delete the old repository after I  
made a patch because otherwise I get some error messages I can't  
handle when I try to update the source code...

Thanks for your patience!

patrick

> HTH,
>
> Carl
>



Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: harmonics and slides II

Carl Sorensen
On 12/20/10 12:01 PM, "Patrick Schmidt" <[hidden email]> wrote:
> Am 20.12.2010 um 19:31 schrieb Carl Sorensen:
>
>> On 12/20/10 11:16 AM, "Patrick Schmidt" <[hidden email]> wrote:

>>
>> Right here, you just type
>>
>> git-cl upload master
> OK, I did that:
>
> pls:~/lilypond-git PLS$ git cl upload master
> This branch is associated with issue 3590041. Adding patch to that
> issue.
> No output from ['git', 'diff', '--no-ext-diff', '--full-index',
> 'master', '-M']
>
> I still can't see any changes on rietveld. I made all the revisions
> in a fresh repository. Is that a problem?

There's not a problem.  The "problem" is that you are working on the master
branch, and I gave you a command that is correct for the way I work, and not
correct for the way you work.

git-cl upload <Commit identifier>

will upload a patch to Rietveld that shows all the differences between the
commit identified in <Commit identifier> (master in your case) and the
current branch's HEAD (also master in your case).

So there are two ways to proceed:

1) Analyze your repository using gitk or git-gui, and figure out what the
appropriate commit is to use for a reference.  This will require some
thinking, and may be a bit hard to get started on.  However, in the long
run, I think it's the most useful.

2) Rebase your current branch on origin/master, then use origin/master as
the reference commit.  This is the easiest to do, but if the rebase fails
you will have a whole different set of issues to wrestle with.  The good
news -- the rebase seldom fails.

I'd recommend you follow option 2:

git pull -r origin master

This command will pull the current version of origin/master, and rebase your
tree to put your changes on top of the current origin.  Then do

git-cl upload origin/master

This will create a Rietveld patch based on the differences between your tree
and the current savannah repository.

>
>>
>> The issue number is related to your git branch.
>>
>>
>> You never specify the issue number.
> But this is recommended in the section on revisions in the CG

Ah, so it is.  But it's recommended only if you have created a new branch.

We need to improve that documentation.  Thanks for pointing out the
weaknesses.


>>
>> .git/config
>>
> I really have to come to grips with git. This information manager
> scares the hell out of me. I always delete the old repository after I
> made a patch because otherwise I get some error messages I can't
> handle when I try to update the source code...

Yes, coming to grips with git would be a good idea.  If you ever want to
have more than one patch active, you need to come to grips with git.  If
you're happy working on one patch at a time, just keep using lily-git, and
look forward to Graham's new feature in lily-git that will support Rietveld
uploads.

git is confusing as heck to get started with.  Let me give you my standard
practice when I want to work on something for lilypond.

I start in my git repository, and do the following:

git checkout master

This gets me to the master branch, where I need to be.

git pull -r origin master

This updates the master branch to the current savannah git repository.

git branch my-new-contribution
git checkout my-new-contribution

These two commands get me working on a new branch.  I can work on this
branch, and it doesn't affect master at all.  I can't hurt *anything* when
I'm working on a new branch.  The only potential I have is that I might make
a mistake and throw away some of my work.

If I add new files, I do

git add my-new-filename

This allows git to track the new file, but it's not yet committed.

When I'm at a stopping point, I do:

git commit -a

This adds all the new and/or changed files to the repository.

Any time I want to post a patch to Rietveld, I do

git pull -r origin master
git rebase master
git-cl upload master

These three commands get the latest version of git, reapply my patches on
top of that version of git, and then upload the patches to Rietveld.

When I want to go back to the unpatched code, I do

git checkout master

Then I can work on another patch set by creating a different branch.



Once I have a patch ready for pushing, I do

git checkout branch-with-patch-ready-for-pushing
git branch temporary-branch
git checkout temporary-branch
git rebase -I master

The first three commands get me to a new branch with the same contents as
the branch with the patch ready for pushing.  The last command starts up an
interactive process that allows me to combine *all* of the git commits on
this branch into a single commit.  That's nice, because it will be just one
patch, instead of a series of patches.

Once I've got the patches combined, I do

git checkout master
git cherry-pick temporary-branch
git pull -r origin master
git push origin master
git branch -D temporary-branch

This applies the patch from temporary-branch to master, gets the latest
savannah updates in case somebody else has pushed a change, and then pushes
the changes to savannah.  It then deletes my temporary branch.

If I didn't have push access to savannah, I'd do the following instead

git checkout master
git cherry-pick temporary-branch
git pull -r origin master
git format-patch master
git branch -D temporary-branch

Then I'd email the created patch to the person who was going to apply it.

HTH,

Carl



Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: harmonics and slides II

Patrick Schmidt-3

Am 20.12.2010 um 20:31 schrieb Carl Sorensen:

> On 12/20/10 12:01 PM, "Patrick Schmidt" <[hidden email]> wrote:
>> Am 20.12.2010 um 19:31 schrieb Carl Sorensen:
>>
>>> On 12/20/10 11:16 AM, "Patrick Schmidt" <[hidden email]> wrote:
>
>>>
>>> Right here, you just type
>>>
>>> git-cl upload master
>> OK, I did that:
>>
>> pls:~/lilypond-git PLS$ git cl upload master
>> This branch is associated with issue 3590041. Adding patch to that
>> issue.
>> No output from ['git', 'diff', '--no-ext-diff', '--full-index',
>> 'master', '-M']
>>
>> I still can't see any changes on rietveld. I made all the revisions
>> in a fresh repository. Is that a problem?
>
> There's not a problem.  The "problem" is that you are working on  
> the master
> branch, and I gave you a command that is correct for the way I  
> work, and not
> correct for the way you work.
>
> git-cl upload <Commit identifier>
>
> will upload a patch to Rietveld that shows all the differences  
> between the
> commit identified in <Commit identifier> (master in your case) and the
> current branch's HEAD (also master in your case).
>
> So there are two ways to proceed:
>
> 1) Analyze your repository using gitk or git-gui, and figure out  
> what the
> appropriate commit is to use for a reference.  This will require some
> thinking, and may be a bit hard to get started on.  However, in the  
> long
> run, I think it's the most useful.
>
> 2) Rebase your current branch on origin/master, then use origin/
> master as
> the reference commit.  This is the easiest to do, but if the rebase  
> fails
> you will have a whole different set of issues to wrestle with.  The  
> good
> news -- the rebase seldom fails.
>
> I'd recommend you follow option 2:
>
> git pull -r origin master
>
> This command will pull the current version of origin/master, and  
> rebase your
> tree to put your changes on top of the current origin.  Then do
>
> git-cl upload origin/master
>
> This will create a Rietveld patch based on the differences between  
> your tree
> and the current savannah repository.

OK, thanks! The changes are now on rietveld (http://
codereview.appspot.com/3590041/). For some reason three other files I  
didn't change were also uploaded?! (lily/optimal-page-breaking.cc;  
lily/page-breaking.cc; po/de.po)  Do I have to get rid off them on  
rietveld? If yes, how?

>
>>
>>>
>>> The issue number is related to your git branch.
>>>
>>>
>>> You never specify the issue number.
>> But this is recommended in the section on revisions in the CG
>
> Ah, so it is.  But it's recommended only if you have created a new  
> branch.
>
> We need to improve that documentation.  Thanks for pointing out the
> weaknesses.
>
That's my fault because the term "new branch" is still a bit abstract  
to me. A while ago I actually got myself Jon Loeliger's book "Git"  
but I never found time to read it...

>
>>>
>>> .git/config
>>>
>> I really have to come to grips with git. This information manager
>> scares the hell out of me. I always delete the old repository after I
>> made a patch because otherwise I get some error messages I can't
>> handle when I try to update the source code...
>
> Yes, coming to grips with git would be a good idea.  If you ever  
> want to
> have more than one patch active, you need to come to grips with  
> git.  If
> you're happy working on one patch at a time, just keep using lily-
> git, and
> look forward to Graham's new feature in lily-git that will support  
> Rietveld
> uploads.
>
> git is confusing as heck to get started with.  Let me give you my  
> standard
> practice when I want to work on something for lilypond.
>
> I start in my git repository, and do the following:
>
> git checkout master
>
> This gets me to the master branch, where I need to be.
>
> git pull -r origin master
>
> This updates the master branch to the current savannah git repository.
>
> git branch my-new-contribution
> git checkout my-new-contribution
>
> These two commands get me working on a new branch.  I can work on this
> branch, and it doesn't affect master at all.  I can't hurt  
> *anything* when
> I'm working on a new branch.  The only potential I have is that I  
> might make
> a mistake and throw away some of my work.
>
> If I add new files, I do
>
> git add my-new-filename
>
> This allows git to track the new file, but it's not yet committed.
>
> When I'm at a stopping point, I do:
>
> git commit -a
>
> This adds all the new and/or changed files to the repository.
>
> Any time I want to post a patch to Rietveld, I do
>
> git pull -r origin master
> git rebase master
> git-cl upload master
>
> These three commands get the latest version of git, reapply my  
> patches on
> top of that version of git, and then upload the patches to Rietveld.
>
> When I want to go back to the unpatched code, I do
>
> git checkout master
>
> Then I can work on another patch set by creating a different branch.
>
>
>
> Once I have a patch ready for pushing, I do
>
> git checkout branch-with-patch-ready-for-pushing
> git branch temporary-branch
> git checkout temporary-branch
> git rebase -I master
>
> The first three commands get me to a new branch with the same  
> contents as
> the branch with the patch ready for pushing.  The last command  
> starts up an
> interactive process that allows me to combine *all* of the git  
> commits on
> this branch into a single commit.  That's nice, because it will be  
> just one
> patch, instead of a series of patches.
>
> Once I've got the patches combined, I do
>
> git checkout master
> git cherry-pick temporary-branch
> git pull -r origin master
> git push origin master
> git branch -D temporary-branch
>
> This applies the patch from temporary-branch to master, gets the  
> latest
> savannah updates in case somebody else has pushed a change, and  
> then pushes
> the changes to savannah.  It then deletes my temporary branch.
>
> If I didn't have push access to savannah, I'd do the following instead
>
> git checkout master
> git cherry-pick temporary-branch
> git pull -r origin master
> git format-patch master
> git branch -D temporary-branch
>
> Then I'd email the created patch to the person who was going to  
> apply it.
>
> HTH,
It does! Thanks for your comprehensive explanations.

patrick
>
> Carl
>



Loading...