Difference between revisions of "CDO/Git"
From Eclipsepedia
(→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> | ||
Latest revision as of 05:12, 10 November 2011
Contents |
[edit] Configuration
[edit] 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:
[edit] Common Tasks
[edit] 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)
[edit] 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