Jump to: navigation, search

Difference between revisions of "CDO/Git"

< CDO
(Line Endings)
 
(9 intermediate revisions by 2 users not shown)
Line 1: Line 1:
= How to create a patch =
+
__TOC__<br>
  
EGit can only create patches describing a single commit. This is inadequate, because it's highly
+
= Configuration =
  
likely that you'll commit many times onto a local branch before you're ready to create a
+
== Line Endings ==
  
single patch covering that series of changes.<br>
+
Make sure your Git system settings contain the property <code>core.autocrlf=true</code>. This is very important so that neither you nor other developers (or the Hudson build) ends up with lots of changed files directly after checkout or, even worse, commit/push wrong line endings. If you don't know how to set this property do not ignore it, ask an expert! Here's a screenshot of the setting in EGit:
  
<br>
+
[[Image:autocrlf.png]]
  
Fortunately Git itself makes patch creation very easy. The most versatile format of its diff command is:
+
= Common Tasks =
<pre># git diff &lt;commit1&gt; &lt;commit2&gt; &gt; mypatch.txt
+
</pre>
+
  
 +
== How to create a patch  ==
  
This creates a patch 'mypatch.txt' describing the differences between commit1 and commit2.
+
EGit can only create patches describing a single commit. This is inadequate, because it's highly likely that you'll commit many times onto a local branch before you're ready to create a single patch covering that series of changes.<br>
  
(Remember that in Git a commit is a ''snapshot'', not a changeset. Therefore, any two commits
+
<br>
  
can be compared.) There are other ways of using git diff, but this is the most generic way
+
Fortunately Git itself makes patch creation very easy. The most versatile format of its diff command is:
 +
<pre># git diff &lt;commit1&gt; &lt;commit2&gt; &gt; mypatch.txt
 +
</pre>
 +
<br> Where <commit1> and <commit2> can be anything identifying a commit, e.g. a branch name, a tag name,
 +
a SHA1 commit-ID, or 'HEAD'. This creates a patch 'mypatch.txt' describing the differences between commit1 and commit2. (Remember that in Git a commit is a ''snapshot'', not a changeset. Therefore, any two commits can be compared.) There are other ways of using git diff, but this is the most generic way of invoking it.<br>
  
of invoking it.<br>
+
<br>  
  
 +
If you're creating a patch for review, then the patch should apply cleanly against ''origin/master''.
  
 +
This suggests the following workflow:
  
If you're creating a patch for review, then the patch should apply cleanly against origin/master.
+
#Develop on a local development branch, committing as often as you like<br>
 +
#Merge ''origin/master'' into your development branch whenever you want, but at least once, right before you create your patch.
 +
#Commit the merge, if it wasn't committed automatically. (Git's default behavior is to commit automatically if there are no conflicts.)
 +
#Run 'git diff' as follows: git diff origin/master HEAD (assuming that your dev branch is checked out, which makes HEAD reference it)
  
This suggests the following workflow:
+
<br>
  
#Develop on a local development branch, committing as often as you like<br>
+
== How to apply a patch  ==
#Merge origin/master into your development branch whenever you want, but at least once, right before you create your patch.
+
#Commit the merge, if it wasn't committed automatically. (Git's default behavior is to commit automatically if there are no conflicts.)
+
#Run 'git diff' as follows: git diff origin/master HEAD (assuming that your dev branch is checked out, which makes HEAD reference it)
+
<br>
+
= How to apply a patch  =
+
  
 
A patch created by 'git diff' is in the ''unified diff'' format, basically the same as the output format of 'diff -c'  
 
A patch created by 'git diff' is in the ''unified diff'' format, basically the same as the output format of 'diff -c'  
Line 39: Line 42:
 
on a *Nix platform. Eclipse cannot apply such a patch. You'll have to use a "real" patch processor, such  
 
on a *Nix platform. Eclipse cannot apply such a patch. You'll have to use a "real" patch processor, such  
  
as Git itself, or GNU patch.
+
as Git itself, or GNU patch.  
  
 +
<br>
  
 
+
With Git, you can apply a patch by invoking Git as follows:  
With Git, apply the patch works as follows:
+
 
<pre>~/my/git/repo# git apply /path/to/mypatch.txt
 
<pre>~/my/git/repo# git apply /path/to/mypatch.txt
</pre>
+
</pre>  
 
+
<br> Or you can apply it with GNU patch as follows:<br>  
 
+
Or with GNU patch:<br>  
+
 
<pre>~/my/git/repo# patch -p1 &lt; /path/to/mypatch.txt
 
<pre>~/my/git/repo# patch -p1 &lt; /path/to/mypatch.txt
</pre>
+
</pre>  
<br>
+
<br>
+
<br>
+
 
+
 
<br>
 
<br>

Latest revision as of 04:12, 10 November 2011


Configuration

Line Endings

Make sure your Git system settings contain the property core.autocrlf=true. This is very important so that neither you nor other developers (or the Hudson build) ends up with lots of changed files directly after checkout or, even worse, commit/push wrong line endings. If you don't know how to set this property do not ignore it, ask an expert! Here's a screenshot of the setting in EGit:

Autocrlf.png

Common Tasks

How to create a patch

EGit can only create patches describing a single commit. This is inadequate, because it's highly likely that you'll commit many times onto a local branch before you're ready to create a single patch covering that series of changes.


Fortunately Git itself makes patch creation very easy. The most versatile format of its diff command is:

# git diff <commit1> <commit2> > mypatch.txt


Where <commit1> and <commit2> can be anything identifying a commit, e.g. a branch name, a tag name, a SHA1 commit-ID, or 'HEAD'. This creates a patch 'mypatch.txt' describing the differences between commit1 and commit2. (Remember that in Git a commit is a snapshot, not a changeset. Therefore, any two commits can be compared.) There are other ways of using git diff, but this is the most generic way of invoking it.


If you're creating a patch for review, then the patch should apply cleanly against origin/master.

This suggests the following workflow:

  1. Develop on a local development branch, committing as often as you like
  2. Merge origin/master into your development branch whenever you want, but at least once, right before you create your patch.
  3. Commit the merge, if it wasn't committed automatically. (Git's default behavior is to commit automatically if there are no conflicts.)
  4. Run 'git diff' as follows: git diff origin/master HEAD (assuming that your dev branch is checked out, which makes HEAD reference it)


How to apply a patch

A patch created by 'git diff' is in the unified diff format, basically the same as the output format of 'diff -c'

on a *Nix platform. Eclipse cannot apply such a patch. You'll have to use a "real" patch processor, such

as Git itself, or GNU patch.


With Git, you can apply a patch by invoking Git as follows:

~/my/git/repo# git apply /path/to/mypatch.txt


Or you can apply it with GNU patch as follows:

~/my/git/repo# patch -p1 < /path/to/mypatch.txt