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.
.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,