[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: CM 1.1 git question

From: Jonathan Kulp
Subject: Re: CM 1.1 git question
Date: Wed, 18 Feb 2009 12:37:51 -0600
User-agent: Thunderbird (X11/20090105)

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. :)


Johannes Schindelin wrote:

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


Jonathan Kulp

Attachment: git-starting.patch
Description: Text Data

reply via email to

[Prev in Thread] Current Thread [Next in Thread]