Re: CM 1.1 git question

[Johannes Schindelin]

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