Skip to main content
Jump to: navigation, search

Difference between revisions of "CDO/Git"

< CDO
(New page: = 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...)
 
 
(12 intermediate revisions by 2 users not shown)
Line 1: Line 1:
= How to create a patch =
+
'''This page is deprecated!'''
  
EGit can only create patches describing a single commit. This is inadequate, because it's highly
+
Please refer to [[CDO_Source_Installation]]...
 +
----
  
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>
+
__TOC__<br>  
  
<br>
+
= Configuration =
  
Fortunately Git itself makes patch creation very easy. The most versatile format of its diff command is:
+
== Line Endings ==
<pre># git diff &lt;commit1&gt; &lt;commit2&gt; &gt; mypatch.txt
+
</pre>
+
  
 +
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:
  
This creates a patch 'mypatch.txt' describing the differences between commit1 and commit2.
+
[[Image:autocrlf.png]]
  
(Remember that in Git a commit is a ''snapshot'', not a changeset. Therefore, any two commits
+
= Common Tasks =
  
can be compared.) There are other ways of using git diff, but this is the most generic way
+
== How to create a patch  ==
  
of invoking it.<br>
+
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>  
  
 +
<br>
  
 +
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>
  
If you're creating a patch for review, then the patch should apply cleanly against origin/master.
+
<br>
  
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>
+
This suggests the following workflow:
#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.)
+
#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)
 
#Run 'git diff' as follows: git diff origin/master HEAD (assuming that your dev branch is checked out, which makes HEAD reference it)
 +
 
<br>
 
<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'
+
== How to apply a patch ==
  
on a *Nix platform. Eclipse cannot apply such a patch. You'll have to use a "real" patch processor, such
+
A patch created by 'git diff' is in the ''unified diff'' format, basically the same as the output format of 'diff -c'
  
as GNU patch. Most *Nix users will have this installed, or can easily obtain it from their distro's repositories.
+
on a *Nix platform. Eclipse cannot apply such a patch. You'll have to use a "real" patch processor, such
  
A Windows user will have to install it from [http://gnuwin32.sourceforge.net/packages/patch.htm GNU's site].
+
as Git itself, or GNU patch.  
  
 +
<br>
  
 
+
With Git, you can apply a patch by invoking Git as follows:
Once you have GNU patch installed, navigate into the working directory of your Git repository, and invoke
+
<pre>~/my/git/repo# git apply /path/to/mypatch.txt
 
+
</pre>
the patch binary as follows:<br>
+
<br> Or you can apply it with GNU patch as follows:<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>  
 
+
 
+
You can add the --dry-run switch if you want to do, well, a dry run. Inside Eclipse you'll have to refresh
+
 
+
your workspace to make EGit aware of the changes.<br>
+
 
+
<br>
+
 
+
 
+
 
+
<br>
+
 
+
 
<br>
 
<br>

Latest revision as of 12:05, 1 November 2016

This page is deprecated!

Please refer to CDO_Source_Installation...




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


Copyright © Eclipse Foundation, Inc. All Rights Reserved.