Difference between revisions of "CDO/Git"
(→Line Endings) |
|||
(9 intermediate revisions by 2 users not shown) | |||
Line 1: | Line 1: | ||
− | + | __TOC__<br> | |
− | + | = Configuration = | |
− | + | == Line Endings == | |
− | + | 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: | |
− | + | [[Image: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.<br> | |
− | + | <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 <commit1> <commit2> > 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> | ||
− | + | <br> | |
+ | If you're creating a patch for review, then the patch should apply cleanly against ''origin/master''. | ||
+ | This suggests the following workflow: | ||
− | + | #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) | ||
− | + | <br> | |
− | + | == How to apply a patch == | |
− | + | ||
− | + | ||
− | + | ||
− | + | ||
− | = 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 | + | |
<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 < /path/to/mypatch.txt | <pre>~/my/git/repo# patch -p1 < /path/to/mypatch.txt | ||
− | </pre> | + | </pre> |
− | + | ||
− | + | ||
− | + | ||
− | + | ||
<br> | <br> |
Revision as of 05:12, 10 November 2011
Contents
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:
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:
- Develop on a local development branch, committing as often as you like
- 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)
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