[tablatures] Re: harmonics and slides II

[Carl Sorensen <c_sorensen@xxxxxxx>]

On 12/20/10 12:01 PM, "Patrick Schmidt" <p.l.schmidt@xxxxxx> wrote:
> Am 20.12.2010 um 19:31 schrieb Carl Sorensen:
> 
>> On 12/20/10 11:16 AM, "Patrick Schmidt" <p.l.schmidt@xxxxxx> 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