Ok I found a typo in the git instructions of CG and followed your
instructions to create the patch using git. Seems to have worked great!
Would someone with push privileges please review the patch and apply if
it looks ok?
Again, Johannes, many thanks for your patience in explaining this to a
non-developer. :)
Jon
Johannes Schindelin wrote:
Hi,
On Wed, 18 Feb 2009, Jonathan Kulp wrote:
Johannes Schindelin wrote:
On Wed, 18 Feb 2009, Jonathan Kulp wrote:
Am I correct in thinking that [git format-patch] creates the patch
by comparing my local (changed) file with the corresponding file in
the remote git repository?
No, it creates patches from commits. So you use Git as usual:
(inspect your changes)
$ git diff
(stage the modified files)
$ git add <files>
(commit the stuff)
$ git commit
(now generate patches from, say, the last 3 commits)
$ git format-patch -3
From the rest of your mail I see that you made work hard on yourself
by not using Git at all...
I don't have commit privileges.
Actually, you do. That is the great thing with Git: once you cloned a
repository, you have a full stand-alone repository in its own right. And
it is all yours. You can do _whatever_ you want with it.
Is this commit command a local commit or...where does it commit to?
Frankly I'm scared of committment. :) I also don't understand which
files it's comparing. When you decide to edit a file, do you work
directly on that file or do you create a working copy or a backup or
what?
The file _is_ the working copy.
Briefly, when working with Git you have
- the working directory (this is where your files live)
- the staging area (also knows as "index" in the Git documentation)
- the current revision (that might be the state last committed by you, or
the state last pulled by you).
The thing to keep in mind: once you committed something, it is part of the
repository. And it is quite difficult to lose it inadvertently. The way
to commit something is to stage the changes ("git add <files>"), and after
that create a new commit ("git commit").
The staging area is a quite useful thing: you can stage changes you
already know you want to commit, continue to work, and then see _only_ the
unstaged changes with "git diff".
Here's my workflow. If you have time, please show how I should modify
it to use the git stuff instead, but I haven't found it to be tedious at
all:
1. Find a typo in a doc
2. git pull origin (to make sure I have the latest of everything)
3. find the sourcefile where the typo is: foobar.itely
4. make a working copy of that file: foobarB.itely
5. fix the typo in foobarB.itely
6. Preview changes by running texi2html. If all is well, proceed...
7. create patch by doing
diff -u foobar.itely foobarB.itely > foobar.patch
8. send patch to someone with commit privileges
I suggest
2. git pull --rebase
This will take all your local commits and try to _reapply_ them on top of
the upstream branch. Example:
Imagine you fixed a typo. You committed the fix locally. Now, somebody
changed the upstream, adding two commits. Your typo has not been
integrated into upstream yet.
Now, a "git pull --rebase" will move your current branch to the current
upstream, and then apply the typo fix again.
If your change has been integrated, the patch will not be applied, as it
is no longer necessary.
3. check again if the typo is still there
4. if it is not, fix it directly in the file (without making a backup)
5. git add <file>
6. git commit
7. git format-patch origin/<branch>
This will create files with the patches and their commit messages.
The thing is: you will get much faster using Git, and you will no longer
have stale backup copies lying around.
There is even a command to send the patches directly to a mailing
list/maintainer: git send-email. I haven't used it yet, though, but you
might find it easier (just Google for it; there are tons of tutorials).
Ciao,
Dscho
--
Jonathan Kulp
http://www.jonathankulp.com
>From 543869a6f8b51a702f4dace4474045729ea1e221 Mon Sep 17 00:00:00 2001
From: Jonathan Kulp <j...@bashtop.(none)>
Date: Wed, 18 Feb 2009 12:26:02 -0600
Subject: [PATCH] Fixed typo: "lastest" to "latest"
---
Documentation/devel/git-starting.itexi | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/Documentation/devel/git-starting.itexi b/Documentation/devel/git-starting.itexi
index dbef6f7..583a70f 100644
--- a/Documentation/devel/git-starting.itexi
+++ b/Documentation/devel/git-starting.itexi
@@ -230,7 +230,7 @@ differ from origin/web. In this case, remember that other people
working like you on the remote web branch of
git://git.sv.gnu.org/lilypond.git/ know nothing about your own web
branch: this means that whenever you use a committish or make a patch,
-others expect you to take the lastest commit of origin/web branch as a
+others expect you to take the latest commit of origin/web branch as a
reference.
This README tries to explain most of Git commands needed for
--
1.5.4.3
_______________________________________________
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel
